Integrating Samba’s DNS server with existing dnsmasq installations

As an Active Directory encompasses not only LDAP and Kerberos but also DNS and there are funny things Microsoft does with DNS (dynamic updates, special SRV records to locate hosts etc.), running Samba as an Active Directory domain controller means running either the built-in DNS server or bind9 with a special DLZ plugin.

dnsmasq integration has been discussed but seems to have been abandoned not so much for technical reasons than rather for lack of real interest on both sides. There is at least this HOWTO that works around the technical issues by teaching dnsmasq the necessary SRV records manually, but even then you won’t have dynamic DNS updates the way Samba needs them and it is more of a hack definitely unsupported by the Samba team than a viable solution.

Running dnsmasq is feasible not so much as an alternative running on the Samba host itself, but, at least in my idea of SOHO networking, it’s pre-destined for embedded devices such as access points and routers and accordingly the default DNS forwarder in OpenWrt. Having DNS resolution depend on a “higher-level” DNS service provided by Samba would contradict that concept. Apart from the fact that Samba’s DNS server would require support for every single feature existing DNS servers (such as dnsmasq) already have — or bind be used, a software I do not really miss particularly much (think zone files).

Obviously I can’t achieve the desired isolation of a basic network service such as DNS and a productive service such as Samba with a single DNS zone, as there is no such thing as zone sharing. So I’ll need two DNS zones: and either or The latter choice would be preferable if we were to seriously use Active Directory features such as forests and sites but also mean that there would be a “parallel forest” of “conventional” DNS zones and the need to have a DNS server that supports delegations. As Samba 4 currently supports running a single Active Directory domain controller only anyway, I’ll go with the former:

DNS zone Managed by Running on dnsmasq OpenWrt-based access point/router Samba “Real” server

Now I do, of course, have only one DHCP service at my “site”. Technically it could supply multiple DNS servers but you wouldn’t want that since you can’t control your clients’ resolvers’ behavior via DHCP (ie. when which DNS server is tried). And there’s no need to, because here comes the elegant part: all clients continue to receive the IP address of an OpenWrt device as DNS server which is authoritative for Requests for * simply get delegated to the Samba host with a dnsmasq configuration such as the following:

# Local dnsmasq instance is responsible for

# DNS delegation for

# If rebind protection is on, this is
# required to avoid warnings on DNS
# rebinding attacks

# Upstream DNS server, handles everything
# outside and

Note that having two DNS zones does not imply that you need to have two IP subnets. It’s perfectly fine to have both and point at and have reverse lookup of the IP address resolve to, as long as you configure Kerberos client configuration accordingly (the rdns = false option described at the end of my sssd-ad configuration post).

This way, if the Samba server goes down, only the zone will be affected, not as a whole. Neat :)

Configuring sssd’s Active Directory provider

Following up on the previous post, here’s how we get sssd to actually provide access to our Samba-driven Active Directory.

I started with the instructions in the Samba wiki but these actually go beyond the minimum that is necessary. Let me also add some context to the individual components and settings involved.

How sssd’s components work together

sssd is quite modular: if you read the sssd.conf man page, you’ll learn about services and domains. You will also learn about different providers such as the already mentioned Active Directory provider that we are going to use. Do not be fooled however: providers are not mutually-exclusive. For example, our Active Directory provider works together with the LDAP and the Kerberos providers as shown here:

Individual sssd components working together
Individual sssd components working together

As a consequence, we’ll have to consider not only sssd-ad configuration directives but also some of those of sssd-ldap and sssd-krb5. And, because sssd-krb5 uses the Kerberos library we’ll also have to consider /etc/krb5.conf.

Configuration explained

Without further ado, here’s an example for a minimal /etc/sssd.conf that takes advantage of autodiscovery:

services=nss, pam


Setting id_provider and access_provider activates sssd-ad as identity provider (ie. the source for user and group information) and access provider (eg. checks if a user is allowed access). However it also activates it as authentication provider (ie. checks passwords) and chpass provider (ie. changes passwords), because id_provider‘s value is a default for auth_provider, which in turn is the default for chpass_provider.

We do not specify ad_domain because the default is to use the configuration section’s name (minus the “domain/” part, of course). We do not specify ad_server either because Samba’s DNS server has automagically set up SRV records for us that sssd-ad/ can use for service discovery.

I disabled dyndns_update for now because it gave me problems. Setting enumerate to true is debatable and recommended for small setups only, but you might want it for playing around with nested groups and see how they work. The default is false.

There’s no need to specify any of ldap_uri, ldap_search_base, ldap_sasl_mech or ldap_sasl_authid, ldap_user_* and ldap_group_*sssd-ad will have taken care of these parameters for you.

ldap_id_mapping is set to true so that sssd itself takes care of mapping Windows SIDs to Unix UIDs. Otherwise the Active Directory must be able to provide POSIX extensions. If yours does, you can omit this option, of course.

It is obligatory to specify krb5_realm, which, by convention, is always upper-case and in most cases will the DNS name of the Active directory. krb5_keytab specifies the keytab file sssd will use to connected to Samba’s KDC (see also: What is a keytab file). The keytab file can be exported on the Samba server as per the Samba Wiki instructions.

Again, krb5_server, krb5_kpasswd will have already been provided by sssd-ad for you.

As you can see the net result is a much simpler configuration than with sssd-ldap and sssd-krb5 alone. Provided you’ve followed the other necessary steps, eg. PAM and NSS configuration (again, see eg. the Samba Wiki instructions), you can now try eg. getent passwd and should be able to see your Active Directory users.

Debugging hints

I had a hard time to get everything working, receiving “GSSAPI Error: Miscellaneous failure (Server not found in Kerberos database)” error messages all the time. Some hints:

  1. Start sssd manually and in debug mode with sssd -i -d 5, choosing the debug level as appropriate.
  2. One can not stress enough: get your DNS working properly. In my case, the DHCP service advertising the DNS servers to use ran on a separate machine, and of course I forgot to specify the IP address of the Samba server there…
  3. The Kerberos client library will do one thing you might not immediately be aware of: reverse DNS lookups. If, for example, you decided to use a separate DNS subdomain for Active Directory (which you definitely do want to do) but let your hostname point at and in turn resolves to, things won’t work unless you specify rdns = false in your /etc/krb5.conf.

    By the way, the only way to really debug such issues is either to run Wireshark or to look at Samba’s logfiles — the client itself won’t even tell you it does such things (reverse lookups and their results) if you strangle it.

Update 08.02.2014: It seems that krb5_realm is not strictly necessary. The krb5_ad provider will take care of that for you:

(Sat Feb  8 23:55:13 2014) [sssd[be[]]] [ad_set_ad_id_options] (0x0100): Option krb5_realm set to AD.MYDOMAIN.FOO.BAR

Making Samba users available locally to Linux systems

In the past, we used to integrate Samba and “native” Linux users by using a single password backend, often LDAP:

User authentication of Linux system and Samba users against LDAP
User authentication of Linux system and Samba users against LDAP

This lead to several moments of pain, from the deficiencies surrounding group membership, the NIS and the rfc2307bis schema (see eg. here and here), over the need to define scripts to execute administrative actions such as adding users, to the not really particularly intuitive LDAP server setup in newer OpenLDAP versions.

Samba has for quite some time offered an alternative solution, by allowing for two separate user databases, the Linux passwd/shadow one and its own, and providing the Linux system with access to its user database through the combination of the winbind daemon and suitable PAM and NSS modules:

User authentication of Linux system and Samba users against LDAP
User authentication of Linux system and Samba users against LDAP

However, as I pointed out before, the Samba4 version of winbind currently lacks some important functionality.

Luckily, this Samba wiki page points out two alternatives (don’t be fooled by this wiki page, which currently only one):

Note that nslcd/pam_ldap/nss_ldap is not PADL’s now-considered dead pam_ldap / nss_ldap but a fork/rewrite. Even this one, however, draws controversy.

Yet, I found it hard to make a decision in the light of rather opinionated information on the Web and rather sparse information on the Samba Wiki. So I tried to come up with a comparison table myself, focussing on integration with Samba 4 and Active Directory features. Note that the table comes with a level of uncertainty, feel free to send me corrections.

sssd / pam_sss / nss_sss (1.11.3) nslcd / pam_ldap / nss_ldap (0.9.2)
Supports unencrypted connections via plain LDAP? Yes Yes
Supports encrypted connections via Kerberos? Yes Yes
SASL required? No Yes
Requires explicit Kerberos ticket renewal eg. through background k5start process? No Yes
Retrieval of POSIX data (UID, GID, home directory, login shell) from a Active Directory provisioned with –rfc-2307 option Optional (if AD provider is used), Required (if pure LDAP provider is used) Required
Separate backends for user/group information and authentication Yes No (but different LDAP sources)
Host must be joined to the domain? No (but advantageous in certain scenarios) No
Supports Site-based discovery? Yes No
Supports Active Directory’s Global Catalog? Yes No
Can resolve Active Directory’s global and universal groups? Yes No
Can resolve group members from trusted domains? Yes No
Leverages Active Directory’s tokenGroups attribute? Yes (also in addition to POSIX attributes) No
Offline authentication possible? Yes Yes?
Latest release 2013 2013

The conclusion: nslcd is a choice for pure LDAP authentication, for Active Directory scenarios one should go with sssd.

Unfortunately, my $distro still shipped with sssd 1.9.5 and you really do want 1.10 or newer because of added features in its Active Directory identity provider. While is it possible to access AD via pure LDAP and with or without Kerberos, you really should use the Active Directory provider because of the reasons given above. See also Jakub Hrozek’s blog and his presentation for additional information on the new features.

So I built and packaged sssd (and Samba) myself — and it took me just a month…

Configuration of sssd for Active Directory will be continued in the next post.

Limited winbind usability with Samba 4

Almost exactly a year ago the first official Samba 4 release saw the light of the world, bringing with it Active Directory Domain Controller support as one of its biggest merits. All relevant Windows APIs had been implemented, thus allowing for all user management to be done through Windows tools such as the “Active Directory Users and Computers” MMC console.

This does of course wake the appetite of moving all users into the AD and let the Linux system authenticate against it as well, a scenario that has been supported through the use of Samba’s winbind for some time now.

As the new “samba” master binary coordinates the other daemons itself, there is no need to start winbindd manually any more. Editing /etc/nsswitch.conf as follows:

passwd: compat winbind
group: compat winbind

makes AD user accounts become visible to the system:

# getent passwd
vscan:x:65:487:Vscan account:/var/spool/amavis:/bin/false
fetchmail:x:486:2:mail retrieval daemon:/var/lib/fetchmail:/bin/false

Note how this output shows two things:

  • “winbind use default domain = yes” does not work: user names are returned including the Samba domain name.
  • Setting “template homedir” does not work: in the example above, it was set to /home/%U, of course, but the “%U” placeholder does not get replaced. Strangely, even if you configure the default values, /home/%D/%U, this won’t work. Comment out the option completely and that very default will work.

Unfortunately, this effectively makes Samba 4 (tested with version 4.1.2 to be precisely) currently quite unusable for the intended purpose.

The first issue has already been reported as Bugzilla #9780. For the second issue there are at least two tickets, Bugzilla #9839 and Bugzilla #9898. According to a comment in the former, the winbindd used in Samba 4 misses support for these placeholders and requires replacement by a combined (Samba 3/Samba 4) winbindd implementation. I do not know of any roadmap for that.