Recently, I have found same articles stating that Red Hat is depreciating
nslcd and choosing
sssd as its successor. Looking for more info about it, I recognized that
sssd offers caching of credentials which means that even in the absence of authentication authority be it LDAP, AD , KRB and so forth users will still be able to log into a host (as long as they have done it before and their data still resides in the local host database). This alone makes migration to
sssd worth the effort! Can you imagine storing all application administrative accounts like oracle, lawson, epicadm and many more in the AD instead locally? Isn’t it great?
If you look around this blog, you will find a few posts about implementing
nslcd based on LDAP/KRB5/AD authentication/authorization with Red Hat. In this environment Active Directory also provides LDAP and Kerberos services and there is PAM component in it also. What follows next, is an illustration of the steps taken to migrate such environment to
sssd. There are many other ways how
sssd could be implemented!
I will backup the existing authentication/authorization environment just in the case I run out of time switching to
sssd and have to restore the system back to its original shape.
# authconfig --savebackup=wmdbackup
Second, we will need to make sure the proper packages are installed:
# yum -y install sssd-client sssd-ldap sssd-ad sssd-krb5
Next, you will need to stop
nscd. We are replacing
sssd for authentication, and since
sssd also does caching, we disable
nscd to keep them from having conflicts:
# service nslcd stop # service nscd stop # chkconfig 2345 nslcd off # chkconfig 2345 nscd off
Now, execute this little command to set
# authconfig --enablesssd --enablesssdauth \ --enablelocauthorize --enablemkhomedir \ --update
Be aware that the last command changes
nsswitch.conf and few other files in the
/etc/pam.d directory. Look for
It is time to edit the
/etc/sssd/sssd.conf starting with setting the appropriate permissions.
# chmod -R 600 /etc/sssd
If these permissions are not exactly as show, the daemon will refuse to start.
In my case, I asked RedHat to provide me this file for my current version of RH which is 6.6. I copied it to the host and after starting
sssd I was allowed me to log-in remotely with no further issues. But there was one caveat with this file as it is currently – it is it guarantees that any user log-in will result in AD wide search. This file identified the
ldap_search_base which is the very top of my domain – all searches have to start from the top and follow every branch till the result is found…. This is not what I want. I want to limit the search (time) to the very specific branches of my AD tree, the ones storing UNIX users log-in and group membership info only. Initially, I included in it the following statements:
ldap_user_search_base=OU=Secured,OU=Corporate Users,DC=wmd,DC=edu ldap_group_search_base=OU=Unix,OU=Security Groups,OU=Corporate Groups,dc=wmd,dc=edu
Normally, the named parameter is normally followed by an equals sign then the values that are to be assigned to that variable, right? Not in this case. With such entries inside the its configuration file
sssd wouldn’t start… After a while of searching, I found one site (http://support.hp.com/us-en/document/c02820186) that has it right! Instead of the equal you have to use the comma character. The whole
sssd.conf is shown bellow.
[sssd] config_file_version = 2 services = nss, pam domains = WMD.EDU debug_level = 4 [domain/WMD.EDU] ldap_id_use_start_tls = False cache_credentials = True id_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_schema = rfc2307bis ldap_force_upper_case_realm = True ldap_user_object_class = user ldap_group_object_class = group ldap_user_gecos = displayName ldap_user_home_directory = unixHomeDirectory ldap_uri = ldap://unixldap.wmd.edu/ ldap_search_base = dc=wmd,dc=edu ldap_user_search_base,OU=Managed By Others,DC=wmd,DC=edu ldap_user_search_base,OU=Shared,OU=Corporate Users,DC=wmd,DC=edu ldap_user_search_base,OU=Secured,OU=Corporate Users,DC=wmd,DC=edu ldap_user_search_base,OU=ServiceAccounts,OU=Corporate Servers,DC=wmd,DC=edu ldap_group_search_base,ou=Unix,ou=Security Groups,ou=Corporate Groups,dc=wmd,dc=edu ldap_default_bind_dn = CN=aixldapquery,OU=ServiceAccounts,OU=Corporate Servers,DC=wmd,DC=edu ldap_default_authtok_type = password ldap_default_authtok = bind_account_password_goes_here ldap_tls_cacertdir = /etc/openldap/cacerts ldap_referrals = false krb5_realm = WMD.EDU krb5_kpasswd = wmddc.wmd.edu krb5_server = wmddc.wmd.edu krb5_canonicalize = False
To make sure that
sssd starts at reboot, we will do this:
# chkconig 2345 sssd on
Let’s start it and test it.
# service sssd start # id duszyk uid=923810(duszyk) gid=216(operator) groups=216(operator) # getent passwd duszyk duszyk:*:923810:216:Duszyk, Waldemar M:/home/duszyk:/bin/bash
The rest that follows are a few general observations that I have developed/learned in my so far very short interaction with
If a user for some reason has a changed UID/GID number, then the SSSD cache must be cleared for that user before that user can log in again. The
sssd-tools package contains the neccesary utilitites.
# yum install sssd-tools # sss_cache -u markd
There can be times when it is useful to seed users into the SSSD database rather than waiting for users to log-in and be added (kickstart comes to mind…?). New users can be added using the
# sss_useradd --UID 501 --home /home/jsmith --groups admin,dev-group jsmith
The cache purge utility,
sss_cache, invalidates records in the SSSD cache for a user, a domain, or a group. Invalidating the current records forces the cache to retrieve the updated records from the identity provider, so changes can be realized quickly. Most commonly, this is used to clear the cache and update all records:
# sss_cache -E
sss_cache command can also clear all cached entries for a particular domain:
# sss_cache -Ed WMD.EDU
If the administrator knows that a specific record (user, group, or netgroup) has been updated, then
sss_cache can purge the records for that specific account and leave the rest of the cache intact:
# sss_cache -u markd
Be careful when you delete a cache file. This operation has significant effects: Deleting the cache file deletes all user data, both identification and cached credentials. Consequently, do not delete a cache file unless the system is online and can authenticate with a user name against the domain’s servers. Without a credentials cache, offline authentication will fail. If the configuration is changed to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
While troubleshooting failed
sssd, remove its cache before restarting
# rm -f /var/lib/sss/db/* # service sssd start