In the past, we used to integrate Samba and “native” Linux users by using a single password backend, often 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:
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 FreeIPA.org 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.