Authentication services in Ubuntu
Bolesław Tokarski
boleslaw.tokarski at tieto.com
Tue May 21 09:37:27 UTC 2013
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
More information about the Ubuntu-devel-discuss
mailing list