System Security Services Daemon (SSSD)

SSSD or the System Security Services Daemon is used by Linux systems as an identity provider and authenticator. It is capable of communicating with backend services such as LDAP, Kerberos, and FreeIPA and exposing them as NSS and PAM interface for system services.

This page does not cover SSSD in great detail, but will go over certain use cases that I had to use it for.

Tasks

Setup LDAP only authentication on RHEL

The following steps will go over the steps needed to set up and configure LDAP only based authentication using SSSD. This will not be using Kerberos as is the usual case when setting up authentication against an Active Directory server.

Log in to the LDAP client machine as root and install the required packages. Use authselect to change the authentication mechanism to use SSSD:

# dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir
# authselect select sssd with-mkhomedir

Next, setup the following files.

• /etc/openldap/ldap.conf - LDAP config. Requires the base DN and server. Optionally, specify the cipher suites.

URI ldap://10.1.1.9
BASE dc=home,dc=steamr,dc=com
TLS_CACERT      /etc/openldap/certs/ca.crt

TLS_CIPHER_SUITE     ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL

Ensure the certificates are placed in /etc/openldap/certs.

• /etc/sssd/sssd.conf - sssd config. You should have at the very least the following:

[sssd]
config_file_version = 2
services = nss, pam
domains = default

[domain/default]

id_provider = ldap
autofs_provider = ldap
auth_provider = ldap
chpass_provider = ldap


ldap_uri = ldap://10.1.1.9
ldap_search_base = DC=home,DC=steamr,DC=com
ldap_default_bind_dn=cn=admin,dc=home,dc=steamr,dc=com
ldap_default_authtok=secret-password

ldap_id_use_start_tls = True
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/certs

Adjust the ldap server and base DN as required. You may use a read-only bind credential instead of an admin one since read permissions aren't required for authentication/identity to work.

• /etc/openldap/certs/ should contain the LDAP server certificate. This is required for authentication to work. Once placed there, run:

# openssl rehash /etc/openldap/certs

Ensure the file permissions are correct. sssd.conf and ldap.conf should be owned by root and chmod 600.

Once everything is in place, start sssd.

Verify identities can be looked up. Test authentication with sssctl user-checks -a=auth username.

Resources:

• https://linux.die.net/man/5/sssd-ldap
• https://access.redhat.com/solutions/4356441

Authentication without joining an Active Directory domain

This use case is to allow your system to authenticate against a Windows AD server via Kerberos using sssd. It does not require joining the Windows domain. The method outlined below also does not retrieve account information either as both /etc/passwd and /etc/groups are managed locally.

These steps have been tested on CentOS 8.

Install SSSD and the Kerberos workstation packages.

# yum install sssd sssd-krb5 krb5-workstation authselect-compat

Configure krb5.conf:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = WIN.EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 WIN.EXAMPLE.COM = {
  kdc = itsodcsrv14.win.example.com
 }

[domain_realm]
 win.example.com = WIN.EXAMPLE.COM
 .win.example.com = WIN.EXAMPLE.COM

At this point, you should be able to successfully obtain a Kerberos ticket:

$ kinit username@WIN.EXAMPLE.COM         # case matters!
Password for username@WIN.EXAMPLE.COM:   # Enter your password

Configure sssd.conf:

[sssd]
config_file_version = 2
services = nss, pam, ifp
domains = win.example.com

[domain/win.example.com]
id_provider = files
debug_level = 5
auth_provider = krb5
chpass_provider = krb5

krb5_realm = WIN.EXAMPLE.COM
krb5_server = ITSODCSRV14.WIN.EXAMPLE.COM:88
krb5_validate = false

Run authconfig to enable sssd and to enable sssdauth. This will set up the required pam configuration and also inject sssd to /etc/nsswitch.conf as a provider. At the very minimum for authentication, sss should be the provider for shadow.

# authconfig --enablesssd --update
# authconfig --enablesssdauth --update

Start sssd with systemctl start sssd. You should now be able to authenticate as a user.

Troubleshooting

Testing authentication using sssd-tools

You can test whether your authentication works using sssd without needing to login to the system from another session using sssctl user-checks. This tool is provided by the sssd-tools package.

$ sssctl user-checks -a=auth leo
user: leo
action: auth
service: system-auth

SSSD nss user lookup result:
 - user name: leo
 - user id: 11163191
 - group id: 11163191
 - gecos:
 - home directory: /home/leo
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: leo
 - uidNumber: 11163191
 - gidNumber: 11163191
 - gecos: not set
 - homeDirectory: /home/leo
 - loginShell: /bin/bash

testing pam_authenticate

Password:
pam_authenticate for user [leo]: Success

PAM Environment:
 - KRB5CCNAME=FILE:/tmp/krb5cc_16311891_wZhhye

Users with uid below 500 or 1000 fails to authenticate

On Red Hat based systems after 7.2, users with a low UID cannot authenticate. This issue usually surfaces itself when the user is provided by LDAP/Kerberos mechanisms but may also affect local users with RHEL 8.

On RHEL 7.2, this behavior is implemented by the following line in /etc/pam.d/{system,password}-auth:

auth        requisite     pam_succeed_if.so uid >= 500 quiet
account     sufficient    pam_succeed_if.so uid < 500 quiet

In RHEL/CentOS/RockyLinux 8 and above, this has changed to use the pam_usertype.so module instead which defines normal users vs system users through values set in /etc/login.defs. As of RHEL 8, the minimum uid for a normal user is set to 1000-60000. The line responsible for this behavior is:

auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular

Could not start TLS encryption. unknown error

SSSD is throwing the following error when trying to use LDAP authentication.

rocky sssd[be[default]][6595]: Could not start TLS encryption. unknown error
rocky sssd[be[default]][6595]: Could not start TLS encryption. unknown error
rocky sssd[be[default]][6595]: Could not start TLS encryption. unknown error

Check the server. This is most likely the LDAP server dropping the TLS connection because the certificates don't match. For self-signed certificates, the server might need to have TLS_REQCERT=try set in /etc/openldap/ldap.conf.

See Also

• On troubleshooting Kerberos authentication without domain join: https://forums.centos.org/viewtopic.php?t=72345