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 ) 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 .
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.
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.
Listing 1: LDIF Instructions
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.
Listing 2: Caching Sudo Rules
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:
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
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.