Table of contents
- Table of contents
- Authentication choice
- Authentication configuration by package
- Automatic configuration of authentication
- Steps forward
The topic of Corporate authentication in Ubuntu need to be taken up, as it is a pain for large deployments.
First - authentication in general. There is a number of authentication services available to an enterprise deployment - open source:
- plain LDAP (optionally including cached credentials with nss-updatedb and pam-ccreds)
- LDAP+Kerberos (optionally including cached credentials with nss-updatedb and pam-ccreds)
SSSD by RedHat
- winbind3 by Samba
- winbind4 by Samba
- Likewise Open/Enterprise
- VAS/QAS/DAS I think it's currently Dells
PowerBroker Identify Services by Beyondtrust
- more, I guess
The packages that are currently supported officially (I mean by Canonical by being included in the main archive) are:
- plain LDAP
Hopefully, the SSL bug in LDAP libraries is now gone (Bug #423252), so the first 2 can be used productively on desktops and/or servers. Note that cached credentials (with nss-updatedb and pam-ccreds) are not officially supported as their respective packages are in universe.
Winbind3 might work for some Active Directory deployments, but sorry - not mine. Perhaps it's a size issue (20k accounts), perhaps it's something else. There's always been problems with Winbind3.
I found that the Linux/Ubuntu community is very helpful, so not having official Canonical support for some pieces of software is ok for me, not sure about other companies. Anyway I find it less troublesome to use common open source solutions than to buy a niche commercial product.
This being said, there is:
- LDAP/Kerberos with cached credentials
SSSD by RedHat
- winbind4 by Samba4
LDAP and/or Kerberos with cached credentials work pretty well, though this solution seems pretty old. Due to the fact that the packages are not supported (nss-updatedb and libpam-ccreds), they are not being re-built against the latest Ubuntu release. A side effect is that they depend on the Berkeley DB that was installed on the build system. A Precise system contained libdb5.1, libdb4.8. The nss caching stuff is split into libnss-db - the NSS backend that reads the cached NSS data (main archive, depends on libdb5.1) and nss-updatedb, which downloads and stores the data into the database (universe archive, depends on libdb4.8). I can see that Raring's packages only depend on libdb5.1, but I am not sure if that's not a pure coincidence.
We are using SSSD with some success now. Thanks to Timo Aaltonen's efforts, the packages available in Precise were working pretty well and were updated to the latest point releases. There is a Main Inclusion Request for SSSD (Bug #903752), I hope it gets included since Saucy.
I heard Samba4 being advertised as the ultimate solution that will solve all the enterprise issues. I hope it really does, though to me it only solves the issues for people running Active Directory and/or Samba4 on DCs. I know the market share is quite larger than those using plain LDAP or MIT Kerberos or some RedHat's Directory Server, but picking Winbind4 as the ultimate solution just does not feel right.
I don't care. It's up to the company behind it to support it in a reliable manner. Rumours have it that they have issues too, fall behind in their releases for new Ubuntu releases, provide a set of their own libraries which land in /opt and more.
Authentication configuration by package
Assuming that the system is being manually configured, below is the help that one gets from the package maintainer scripts.
If you install libpam-ldap or libnss-ldap, they depend on ldap-auth-config, which configures /etc/ldap.conf. ldap-auth-config depends on auth-client-config, which configures /etc/nsswitch.conf, and on libpam-ldap and libnss-ldap. You can't have a package without its config nor vice-versa.
The current authentication configuration is based on an example ldap.conf. This defaults to an LDAP attribute set that matches one provided by OpenLDAP, but if you have whatever else (Active Directory, Novell NDS, not sure about RedHat's DirServ), you need to configure /etc/ldap.conf yourself anyway. So I'd say it's "best effort" configuration.
I believe Kerberos config (krb5-config) is a little better. Although I needed to adjust the encryption types after configuration, I think I am an exception and the Kerberos configuration actually works in most environments out of the box.
SSSD does not provide a configuration for you aside from entries to /etc/nsswitch.conf and PAM. You are pretty much on your own editing /etc/sssd/sssd.conf yourself.
Automatic configuration of authentication
Now, because I have people running Ubuntu in my company in multiple countries and it would be too trobulesome to configure everything by myself, I'm not doing it And believe me or not, unless you have a Ubuntu client environment of more than 5 machines, you should not be doing it, either.
We are using CFEngine here to install the packages required for authentication, copy working configuration files to /etc. Other parties might be using puppet, chef or hand-crafted shell scripts or they copy the configs from a machine where they previously managed to configure the system properly.
Below I will try to explain how the easy the automated configuration of particular solution is.
The fact that ldap-auth-config and auth-client-config are separate from the LDAP packages is good. It is theoretically possible to not install these packages and deploy the configs automatically with tools mentioned above. In practice it's difficult because the LDAP packages depend on them. This is unlike in Debian, it seems to be one of the Ubuntu specific changes.
As a side effect, during package installation you will be asked about ldap URI etc, which you do not want to fill, as you will be overwriting the configs anyway.
On the positive side, it is possible to create a dummy package that provides ldap-auth-config and auth-client-config and those questions do not pop-up.
This one is ok. It doesn't pop any questions, just gets the job done.
krb5-config is a similar story to ldap-auth-config, aside the fact that it is a dependency on both Debians and Ubuntus. You also get pop-ups with questions etc.
On the positive side, it is possible to create a dummy package that provides krb5-config and those questions do not pop-up.
SSSD is easy to deploy. Just put the config in place.
I believe it is crucial to pick a preferred authentication solution for Ubuntu. Of course local file authentication is good for most cases, but when there is some directory service, it should be at least one obvious, preferred and supported method.
Currently this seems to be LDAP and Kerberos using libnss-ldap, libpam-ldap and/or libpam-krb5, but this is not perfect, as mentioned before.
I strongly vote for this to be SSSD. RedHat is actively developing it and it seems to be running quite decently on Precise already. For this, the following obstacles need to be handled:
- SSSD needs to be included in main (Main Inclusion Request #903752)
- SSSD lacks some configuration questions. I'm ok with that, I deploy it with CFEngine, but I guess it might be considered a requirement
I like RedHat's approach of providing a separate piece of software that configures authentication. If you don't like it or you want to configure it with CFEngine or with text files, you don't run it or you don't even install it. If the configuration absolutely needs to be done inside package maintainer scripts, I would lower the question's priorities, those are too difficult to be answered by average user anyway.
Samba4's winbind might be a good official alternative, but that assumes you have AD. Samba3's winbind can be abandoned.
Let us gather the interested parties and synchronize some actions on this.