Configure SSSD For LDAP on CentOS 7

By | 2019-08-13
0 Comment

While I prefer nss-pam-ldapd for authentication and password resolution on Linux systems, sssd has a few advantages. I consider the biggest advantage of SSSD is the ability to cache credentials. I am going to assume you have a directory server up and running. If not, you can always follow my guides on installing OpenLDAP and configuring it for Linux authentication. If you follow my guides, do not skip TLS configuration. SSSD requires TLS for authentication.

Install SSSD

Install the SSSD packages:

# yum install sssd

Configure SSSD

Create a Configuration File

Create the file /etc/sssd/sssd.conf with the following contents, replacing the highlighted portions with what is relevant to your system. Lines beginning with # are comments. The comments in the example explain what the various options do.

[sssd]
services = nss, pam 
# Which SSSD services are started.
# A separate process for each service is started

#debug_level = 9
# The amount of detail in the logs. Uncomment this and adjust as needed.
# Level 9 is the most detailed level available.

domains = tylersguides
# A list of domains to check when a client makes a request. They are
# checked in the oder listed. The domains listed must have a matching
# configuration section in the format [domain/domainname]

[pam]
# The verbosity of output and logging related to PAM requests. Uncomment
# and adjust as needed. As with the main section, 9 is maximum verbosity.
#pam_verbosity = 9
#debug_level = 9

[domain/tylersguides]
cache_credentials = true
# This enables or disables credential caching. I.e. after successfully
# authenticating a user, the credentials will be stored locally. If the 
# domain is unavailable, users will still be able to login using the 
# cached information.

#account_cache_expiration = 0
# By default, the credential cache never expires. If you want sssd to 
# remove cached credentials, this option will cause them to expire 
# after the number of days it is set to.

#debug_level = 9
# The verbosity of this domains log file.

id_provider = ldap
# SSSD can resolve user information from a number of different sources
# such as LDAP, local files, and Active Directory. This option sets
# the domain's source of identity information. 

#auth_provider = ldap
# As with identity providers, SSSD can authenticate in a variety of ways.
# By default, SSSD will use the value of id_provider.

access_provider = ldap
# The access provider controls the source for determining who is allowed
# to access the system. Even if a user successfully authenticates, if they
# don't meet the criteria provider by the access provider, they will be
# denied access.

ldap_access_order = filter
ldap_access_filter = (objectClass=posixAccount)
# These define the criteria the access provider uses to control who
# is allowed to login. In this case, any user that matches the 
# LDAP filter in this example will be allowed access. Any entry
# that has an objectClass of posixAccount will be allowed access.

ldap_uri = ldaps://centos.tylersguides.com:636
# The URI(s) of the directory server(s) used by this domain.

ldap_search_base = dc=tylersguides,dc=com
# The LDAP search base you want SSSD to use when looking
# for entries. There are options for search bases for various types
# of searches, such as users. Read the sssd-ldap man page for details.

ldap_tls_cacert = /pki/cacerts.pem
# The file containing CA certificates you want sssd to trust.

ldap_tls_cipher_suite = HIGH
# The TLS ciphers you wish to use. SSSD uses OpenSSL style cipher
# suites

ldap_default_bind_dn = cn=osproxy,ou=system,dc=tylersguides,dc=com
# The DN used to search your directory with. It must have read access to
# everything your system needs.

ldap_default_authtok = PASSWORD
# The password of the bind DN.

ldap_tls_reqcert = demand
# This defines how sssd will handle server certificates. Demand means
# that we are requiring the host portion of the URI to match the
# certificate's subject or an SAN, the current time is within the valid
# times on the certificate, and that it's signing chain ends with a CA
# in the file defined by ldap_tls_cacert.

Set the permissions on the configuration file:

# chown root:root /etc/sssd/sssd.conf
# chmod 600 /etc/sssd/sssd.conf

Enable and Start SSSD

The following command will enable SSSD to start at boot time.

# systemctl enable sssd

Now start SSSD:

# systemctl start sssd

Configure NSS and PAM

Run the following command as root to configure PAM and NSS.

# authconfig --enablesssdauth --enablesssd --updateall

Test Your Configuration

I am assuming you already have at least one user on your directory server. If not, create one.

I have the following entries on my test server:

dn: cn=testgroup,ou=groups,dc=tylersguides,dc=com
objectClass: posixGroup
cn: testgroup
gidNumber: 5000
memberUid: testuser

dn: uid=testuser,ou=users,dc=tylersguides,dc=com
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: First Name
sn: Last Name
uid: testuser
uidNumber: 5000
gidNumber: 5000
homeDirectory: /home/testuser
loginShell: /bin/sh
gecos: Full Name

I will create a home directory for testuser and give it ownership of it:

# mkdir /home/testuser
# chown testuser:testgroup /home/testuser

If all is well, the commands will succeed. If you get an error similar to following, I included a short troubleshooting at the end of this guide.

chown: invalid group: ‘testuser:testgroup'

Now try to login as the user:

# ssh -l testuser localhost
testuser@localhost's password: 
Last login: Sun Aug 11 19:34:35 2019 from localhost
-sh-4.2$

Troubleshooting

When setting up my example machine to write this guide, I encountered a few problems. I created this list to help resolve what I foresee to be common problems.

  • SELinux can prevent SSSD from reading files it needs. Try running the command setenforce 0 as root, restarting SSSD and seeing if the problem goes away.
  • If you are using a self-signed certificate on your directory server(s), make sure the subject or SAN of the certificate matches the host portion of the URI(s) in /etc/sssd/sssd.conf
  • Verify the permissions of /etc/sssd/sssd.conf. It must be owned owned by root and only accessible by the owner (mode 600).
  • Make sure the signing CA certificate or self-signed certificate is in the file defined by ldap_tls_cacert.
  • Verify any search filters, such as the one used by ldap_access_filter are working. You can use ldapsearch to test them.
  • Check to make sure the proxy user defined by ldap_default_bind_dn can read the relevant entries and attributes. Use the value of ldap_default_bind_dn with ldapsearch to verify it has the access it needs. Use the -W option and paste the password from ldap_default_authtok when prompted. This will verify the password as well.
  • If you are able to resolve UIDs but not log in, try to login using an account with a UID greater than 1000. The default PAM configuration will not allow accounts with a UID of less than 1000 to authenticate through LDAP.
  • Uncomment the debug level lines in your configuration file and restart SSSD. The SSSD logs can be found in /var/log/sssd.

References

See Also