Detached

While I was having lunch with a colleague recently, conversation turned to the topic of SSSD and new features in Fedora 17. We also talked about sudo integration and other useful functions. Just to remind you: SSSD (System Security Services Daemon [1]) is the client-side daemon that handles communications between clients and centralized directory services.

Various authentication mechanisms can be used for this, and communication with the client is handled by classic PAM and NSS interfaces. Different security providers are then on the back end to handle, for example, communications with an LDAP or FreeIPA server [2].

The good thing about this setup is that authentication for a client will still work if the central back end server is not available. Of course, this can happen if the server crashes, but the cause is often much more trivial. For example, roaming users who do not always have a network connection for their laptops will obviously not always be able to communicate with a central directory service.

SSSD uses the cache to store authentication information. If the user wants to log in to the system, but the central server is not available on the back end, the login will still work because the information is taken from the SSSD cache in this case. The /etc/sssd/sssd.conf configuration file also defines precisely how this cache can be used. For example, the offline_credentials_expiration parameter defines how long the data from the cache will remain valid if the back-end server is not available.

The offline_failed_login_attempts instruction ensures that a user cannot make an arbitrary number of attempts to guess another user's password. Once the integer defined here has been exceeded, the attacking user is then blocked for the time defined in the offline_failed_login_delay parameter before they are allowed to make another login attempt. If this option is set to 0, login is simply impossible as long as the back-end server remains unavailable.

A problem occurs with this approach if, say, the sudo rules for users, or even whole groups, are stored on a central LDAP server on the back end. Sudo references the /etc/nsswitch.conf file to check which back ends should search for rules. Typically, you will find an entry like sudoers = files ldap here. In this case, communication will be directly with the LDAP server. If the server is not available, the request will obviously draw a blank, and the user will be unable to perform the desired action because it is impossible to verify whether the action is allowed for the user.

SSSD solves this problem by also storing the sudo information in the cache. To do this, the sudo software must be extended by adding a plugin so that the request really is passed on to the SSSD if you have the corresponding entry in your /etc/nsswitch.conf file. SSSD also needs a new security provider to accept requests from the sudo tool. The current sudo and SSSD versions in Fedora 16 already have this support built-in.

If you want to try this and have not stored any sudo rules in LDAP, it will be helpful if you do the following: The LDIF file shown in Listing 1 should be loaded onto your preferred LDAP server (e.g., with ldapadd). The instructions first create the ou=SUDOers container in which the sudo rules are stored. This example has two of them: one for the goodboys and one for the badboys. Good boys are allowed to edit all of the files on the system because they are always well-behaved. Bad boys still need to learn how to behave and are thus only allowed to read the files.

01 dn: ou=SUDOers,dc=tuxgeek,dc=de
02 objectClass: top
03 objectClass: nsContainer
04 ou: SUDOers
05
06 dn: cn=goodboys_rule,ou=SUDOers,dc=tuxgeek,dc=de
07 objectClass: top
08 objectClass: sudoRole
09 cn: goodboys_rule
10 sudoUser: %goodboys
11 sudoHost: ALL
12 sudoCommand: /usr/bin/vim
13
14 dn: cn=badboys_rules,ou=SUDOers,dc=tuxgeek,dc=de
15 objectClass: top
16 objectClass: sudoRole
17 cn: badboys_rules
18 sudoUser: %badboys
19 sudoHost: ALL
20 sudoCommand: /usr/bin/less

To make sure importing this to your LDAP server really works, your server must have a matching schema; otherwise, it will complain about too many unknown attributes, and the LDIF import will fail. Fortunately, sudo comes with a matching schema out of the box. If you have Fedora, you will find schemas for various LDAP servers in the /usr/share/doc/sudo-1.8.x/ directory. Again, you can use ldapadd to push them onto your LDAP server.

To make sure the SSSD also knows about its new security provider, you will need to change its configuration in the /etc/sssd/sssd.conf file. Listing 2 shows an example of a configuration with an LDAP server on the back end, and you could use a FreeIPA server for this. If you decide to do so, the man page for sssd.conf can help and provides a sample configuration.

01 [sssd]
02 services = nss, pam, sudo
03
04 [sudo]
05 sudo_cache_timeout = 180
06
07 [domain/LDAP]
08 enumerate = true
09 cache_credentials = TRUE
10 ldap_sudo_refresh_enabled = TRUE
11 ldap_sudo_refresh_timeout = 300
12
13 id_provider = ldap
14 auth_provider = ldap
15 chpass_provider = ldap
16
17 ldap_uri = ldap://ldap.tuxgeek.de
18 ldap_user_search_base = dc=tuxgeek,dc=de
19 ldap_sudo_search_base = "ou=SUDOers,dc=tuxgeek,dc=de"
20 ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

To make sure the cache doesn't just contain rules that have been called once by a user, you definitely need to run the following two commands: ldap_sudo_refresh_enabled and ldap_sudo_refresh_timeout.

These commands ensure that all of your sudo rulesets are loaded by your LDAP server at regular intervals. To make sure the new security provider that comes courtesy of the SSSD servers is addressed, you also need to add the following line to your /etc/nsswitch.conf file:

sudoers = files sss

After restarting the SSSD service, it is now capable of storing your sudo rules on a local cache. Request performance should be better from now on, even for online operations, because it is no longer necessary to open a connection to the LDAP server for every single request. All LDAP requests now use a single connection from SSSD to the LDAP server. Finally, I should mention that I assume user authentication is already handled by the SSSD. If this is not the case, you need to call system-config-authentication to change it.