A few months ago we had a blog entry about shared and personal laptops in schools. The goal of shared laptops is basically that they should behave mostly like shared thin clients: it should not matter which a computer any user chooses to work with. He should simply be able to pick any machine, login and get his own personal desktop environment, with his own documents and, for example, web browser bookmarks.

The problem of an accessible home directory could perhaps be solved satisfactorily with network filesystems such as NFSv4 or AFS, or alternatively with a synchronisation tool such as unison. But even a more essential problem is user management. How is it decided who may login into a laptop, and how is she authenticated and her user information (such as her name, but possibly other information) transmitted to the laptop?

With centralized directory services containing user information, such as NIS or LDAP, one way of solving the problem could be to replicate all data to laptops. We could run an LDAP slave server on every laptop, but that would not be very secure in case we stored the (hashed) password data in LDAP, because all the password hashes of all users would thus exists on every laptop. The LDAP slave servers would also need a relatively unrestricted access to the master LDAP server, to synchronise their contents. We have not tried to do this with laptops in Opinsys, and probably never will.

What we have previously done: we perform authentication on laptops against a web server through an SSL-protected http-connection. The web server performs further authentication against Kerberos/LDAP. In case this authentication is successful, the web server sends information about user’s name (and login), that is then used as a new user is created on the laptop. The authentication token (a password) is stored on the laptop in a hashed format, permitting logins when a laptop is not connected to any network.

This means that any user who has a login and knows his password may pick a shared laptop and login, and in case the network is up and the services work, he may login later to the same laptop, even when the network is down. But the way this is currently done is a kind of a hack: we do this with some PAM and Perl trickery, and we don’t support removing users, or changing their information, or including any information about their group memberships. Kerberos tickets are not received on the laptop, even though they might be useful on some circumstances. This scheme is not bad because it does work for most cases, but it could definitely be better.

SSSD — a solution

Enter System Security Services Daemon, or SSSD for short. This software is a Fedora subproject and is still quite new. I do recommend exercising at least some caution when picking a new technology, especially when it provides some critical and security related functionality. Thus, do not blindly try this without evaluating first whether or not SSSD really fits your needs. But SSSD does seem to provide functionality which fits very well with the shared laptop concept. Simply put, SSSD provides access to remote authentication servers and directories such as Kerberos and LDAP, and caches information so that it can be used when network is down. It does need direct access to these services, but problems that exist in our current HTTPS/PAM/Perl-hack should be no more — as a whole it appears to provide what we need with a more clean design.

SSSD provides access to remote authentication servers and directories such as Kerberos and LDAP, and caches information so that it can be used when network is down.

What follows are some simple instructions on settings up SSSD on Ubuntu, version 10.04 (Lucid Lynx). Hopefully this will be of some use for people using other systems as well. Currently, if you are using Kerberos, I recommend getting sssd packages from our Launchpad repository because of this problem. The same problem is also referred to in this post by an SSSD developer. There is also another problem relating to Kerberos support in the Ubuntu repository package, which probably deserves a bug report… If you do not use Kerberos, the current SSSD packages in Ubuntu repositories should be fine.

Next, we install the SSSD package:

sudo apt-get install sssd

Configuration for SSSD is done in /etc/sssd/sssd.conf. sssd.conf(5) manual page should tell you most of what you need about configuration parameters, but do check out at least sssd-krb5(5) and sssd-ldap(5) as well. (Thankfully some people still write decent manual pages — the one true documentation format for unix systems.) Here we set up an sss domain named KRBLDAP.EDU.EXAMPLE.ORG which uses Kerberos for authentication and LDAP for user information. Edit ”domains” line in /etc/sssd/sssd.conf:

domains = KRBLDAP.EDU.EXAMPLE.ORG

In the same file we should tell sssd what this domain actually means. We make it use kerberos.edu.example.org as the Kerberos server, using EDU.EXAMPLE.ORG as the Kerberos realm, and ldap.edu.example.org as the ldap server. Note that KRBLDAP.EDU.EXAMPLE.ORG is an arbitrary string and it does not need to be related in any way to the Kerberos realm, but for clarity this is perhaps a good naming scheme. Setting up Kerberos and LDAP servers are beyond the scope of this blog posting. Do check out the meaning of the following options from the manual pages, and add this to /etc/sssd/sssd.conf:

[domain/KRBLDAP.EDU.EXAMPLE.ORG]
auth_provider = krb5
krb5_kdcip = kerberos.edu.example.org
krb5_realm = EDU.EXAMPLE.ORG
id_provider = ldap
ldap_uri = ldap://ldap.edu.example.org
ldap_search_base = dc=edu,dc=example,dc=org
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/slapd-ca-cert.pem
cache_credentials = true
enumerate = true

Restart sssd after editing the configuration:

sudo service sssd restart

Now that we have sssd up and running, it is time to configure NSS and PAM to use it. One way to achieve this is to use the auth-client-config package:

sudo apt-get install auth-client-config

Write the following sss authentication profile into /etc/auth-client-config/profile.d/sss:

[sss]
nss_passwd=     passwd:         compat sss
nss_group=      group:          compat sss
nss_shadow=     shadow:         compat
nss_netgroup=   netgroup:       nis

pam_auth=       auth    [success=3 default=ignore]      pam_unix.so nullok_secure try_first_pass
                auth    requisite                       pam_succeed_if.so uid >= 500 quiet
                auth    [success=1 default=ignore]      pam_sss.so use_first_pass
                auth    requisite                       pam_deny.so
                auth    required                        pam_permit.so

pam_account=    account required                                        pam_unix.so
                account sufficient                                      pam_localuser.so
                account sufficient                                      pam_succeed_if.so uid < 500 quiet
                account [default=bad success=ok user_unknown=ignore]    pam_sss.so
                account required                                        pam_permit.so

pam_password=   password        sufficient      pam_unix.so obscure sha512
                password        sufficient      pam_sss.so use_authtok
                password        required        pam_deny.so

pam_session=    session required                        pam_mkhomedir.so skel=/etc/skel/ umask=0077
                session optional                        pam_keyinit.so revoke
                session required                        pam_limits.so
                session [success=1 default=ignore]      pam_sss.so
                session required                        pam_unix.so

Note that editing NSS and PAM settings can be rather dangerous! I suggest you keep a root shell open while doing this, and be ready to revert the changes in case something goes wrong. Once you are properly prepared, do this:

sudo auth-client-config -n -a -p sss

Nothing actually happened, which is okay, now read the auth-client-config(8) manual page on how to fix the above command to do some actual changes, and while at it also check out how to back out the changes with the same command, because you just might need that.

Now it should work. Test it with getent, test it with su, try to login through gdm with users that are listed in LDAP. Yet often we do not get it right the first time, which means it may be time to run sssd interactively with some debugging options on.

sudo service sssd stop
sudo sssd -i -d 4

Here, the -d switch may take any value between 0 and 10 (inclusive) — this controls debug output level. This allows you to see what sssd is doing as you login, or lookup a username, or whatever it is that you are doing that is somehow sssd related.

There is quite a bit more to sssd than this short introduction. So far the version 1.0.2 seems pretty good — at least the project has some decent documentation and sssd problems are rather easy to debug, so perhaps also you might want to give it a try?

Juha Erkkilä