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
domains = KRBLDAP.EDU.EXAMPLE.ORG
[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
sudo service sssd restart
sudo apt-get install auth-client-config
[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
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
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?