Authentication services in Ubuntu

[Bolesław Tokarski]

Hello,

I put some time and effort creating this, please read at the very least 
introduction and suggestions.

= Introduction =

I am a maintaining the Ubuntu deployment in Tieto company. We have over 
500 Ubuntu desktops. I am also trying to gather the Ubuntu Enterprise 
community (see https://launchpad.net/~enterprise-ubuntu and its mailing 
list). The group is open so feel invited.

I would like to take up the topic of Corporate authentication in Ubuntu 
and base my actions depending on the direction Ubuntu heads for.

= Authentication choice =

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
and proprietary:
- Likewise Open/Enterprise
- Centrify
- VAS/QAS/DAS I think it's currently Dells
- PowerBroker Identify Services by Beyondtrust
- more, I guess

== Open source+supported ==

The packages that are currently supported officially (I mean by 
Canonical by being included in the main archive) are:
- plain LDAP
- LDAP+Kerberos
- winbind3

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.

== Open source+unsupported ==

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.

== Proprietary ==

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.

== LDAP configuration ==

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.

== Kerberos 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 ==

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. Also, because you need some other backend 
too, you likely get LDAP and Kerberos backends too. This causes you to 
have 3 authentication modules in PAM and 2 NSS backends in NSS (I might 
be wrong about the latter, though).

== winbind3/winbind4 ==

Can't say.

= 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.

== LDAP ==

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.

== pam-ccreds/nss-updatedb ==

This one is ok. It doesn't pop any questions, just gets the job done.

== Kerberos ==

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 ==

SSSD is easy to deploy. The problem is that you probably also need the 
backends - LDAP and Kerberos and actually those configurations interfere 
with SSSD and you get install-time questions.

== winbind3/winbind4 ==

Can't say.

== Proprietary ==

Can't say.

= Suggestions =

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
- SSSD will likely use libnss-ldap and either libpam-ldap or 
libpam-krb5. Those do not need to be configured and if there is any use 
of it, these variables should be taken from sssd's config dialogs.

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.

= Conclusions =

To the very least, I would like to know a decision. I am not able to fix 
all the stuff myself, particularly because I am not managing any of the 
packages, but I can help with some tasks.

Cheers,
Ballock