SSSD (System Security Services Daemon) connects a Linux server to a central directory such as OpenLDAP, FreeIPA or Active Directory, so users log in with their directory account instead of a local one. It plugs into NSS (user and group lookups) and PAM (authentication), and caches identities and credentials so logins keep working during short directory outages. In this tutorial you will configure SSSD on Ubuntu 24.04 against an LDAP server over TLS, create home directories automatically, restrict logins to specific groups and load sudo rules from the directory. A short section at the end covers joining an Active Directory domain instead.

Prerequisites

To follow this guide you need:

  • A server running Ubuntu 24.04 LTS, for example a CubePath VPS, and a non-root user with sudo privileges.
  • An LDAP server reachable from the server over LDAPS (port 636) or StartTLS (port 389), with users using the posixAccount object class (uidNumber, gidNumber, homeDirectory, loginShell).
  • A read-only service account (bind DN) in the directory, for example cn=sssd-reader,ou=ServiceAccounts,dc=example,dc=com.
  • The CA certificate that signed the LDAP server's TLS certificate, if it is not issued by a public CA.
  • At least one test user in the directory, called jdoe in this guide.

Replace ldap.example.com, dc=example,dc=com and example.com with your own values.

Step 1 - Installing SSSD and the LDAP tools

Install SSSD with its LDAP backend, the NSS and PAM modules, sudo integration and the OpenLDAP client tools used for testing:

sudo apt update
sudo apt install -y sssd-ldap sssd-tools libnss-sss libpam-sss libsss-sudo ldap-utils

The service does not start yet because there is no configuration. Confirm the installed version:

sssd --version

2.9.4

Step 2 - Trusting the directory's CA and testing the connection

SSSD refuses to send passwords over an unencrypted or unverified connection, so the server must trust the CA of the LDAP server. If your directory uses a private CA, copy its certificate (PEM format, .crt extension) into the system trust store:

sudo cp ldap-ca.crt /usr/local/share/ca-certificates/ldap-ca.crt
sudo update-ca-certificates

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Before touching SSSD, confirm that the bind account can search the directory over TLS. Enter the service account password when prompted:

ldapsearch -H ldaps://ldap.example.com -D "cn=sssd-reader,ou=ServiceAccounts,dc=example,dc=com" -W -b "dc=example,dc=com" "(uid=jdoe)" uid uidNumber gidNumber homeDirectory

dn: uid=jdoe,ou=People,dc=example,dc=com
uid: jdoe
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/jdoe

If this fails with Can't contact LDAP server, fix DNS, the firewall or the CA first. SSSD will not work until this search does.

Step 3 - Writing the SSSD configuration

Create the main configuration file:

sudo nano /etc/sssd/sssd.conf

Paste the following, replacing the domain name, URI, search bases and bind credentials with yours:

[sssd]
services = nss, pam, sudo
domains = example.com

[domain/example.com]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = simple
sudo_provider = ldap

ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_user_search_base = ou=People,dc=example,dc=com
ldap_group_search_base = ou=Groups,dc=example,dc=com
ldap_sudo_search_base = ou=Sudoers,dc=example,dc=com

ldap_default_bind_dn = cn=sssd-reader,ou=ServiceAccounts,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = your_bind_password

ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

cache_credentials = true
enumerate = false

simple_allow_groups = linux-admins, developers

[pam]
offline_credentials_expiration = 3

What the important options do:

  • id_provider and auth_provider = ldap look users up and verify passwords against the directory.
  • access_provider = simple with simple_allow_groups lets only members of those directory groups log in. Everyone else is denied, even with a valid password. Use simple_allow_users for individual accounts.
  • ldap_tls_reqcert = demand rejects servers whose certificate cannot be verified.
  • cache_credentials = true stores a hash of the last successful password so users can log in while the directory is unreachable, for up to offline_credentials_expiration days.
  • enumerate = false avoids downloading the whole directory. Lookups of individual users and groups still work.

If your server only offers StartTLS on port 389, use ldap_uri = ldap://ldap.example.com and add ldap_id_use_start_tls = true.

SSSD refuses to start unless the file is owned by root and not readable by anyone else, which also protects the bind password:

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

Validate the syntax and option names:

sudo sssctl config-check

Issues identified by validators: 0

Messages generated during configuration merging: 0

Used configuration snippet files: 0

Enable and start the service:

sudo systemctl enable --now sssd
sudo systemctl status sssd --no-pager

● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
     Active: active (running) since ...

Step 4 - Checking NSS and PAM integration

Installing libnss-sss adds sss to the relevant lines of /etc/nsswitch.conf. Confirm it:

grep -E '^(passwd|group|shadow|sudoers)' /etc/nsswitch.conf

passwd:         files systemd sss
group:          files systemd sss
shadow:         files systemd sss
sudoers:        files sss

If the sudoers line is missing, add sudoers: files sss to the end of the file with sudo nano /etc/nsswitch.conf.

Now look up the directory user. These commands go through NSS, so a result proves SSSD is answering:

getent passwd jdoe
id jdoe

jdoe:*:10001:10001:John Doe:/home/jdoe:/bin/bash
uid=10001(jdoe) gid=10001(jdoe) groups=10001(jdoe),20000(linux-admins)

libpam-sss registers itself in the PAM stack through pam-auth-update. Directory users do not have a home directory on this server yet, so enable automatic creation on first login:

sudo pam-auth-update --enable mkhomedir

Check that SSSD considers the domain reachable:

sudo sssctl domain-status example.com

Online status: Online
...

Finally, log in as the user from another terminal. Password SSH logins require PasswordAuthentication yes (or KbdInteractiveAuthentication yes) in /etc/ssh/sshd_config:

ssh jdoe@your_server_ip
pwd

Creating directory '/home/jdoe'.
/home/jdoe

A user outside linux-admins and developers gets Permission denied even with the right password, and /var/log/auth.log shows pam_sss(sshd:account): Access denied.

Step 5 - Loading sudo rules from LDAP

With sudo in services and sudo_provider = ldap, SSSD reads sudoRole entries below ldap_sudo_search_base. Your directory needs the sudo schema loaded (OpenLDAP ships it as the sudo schema; FreeIPA has its own sudo rules). An example rule that grants full sudo to the linux-admins group:

dn: cn=linux-admins-all,ou=Sudoers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: linux-admins-all
sudoUser: %linux-admins
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL

Add it with ldapadd using an account allowed to write to ou=Sudoers. On the client, SSSD refreshes sudo rules periodically. Force a refresh and list the rules for the test user:

sudo sss_cache -E
sudo -l -U jdoe

User jdoe may run the following commands on server01:
    (ALL) ALL

Local rules in /etc/sudoers and /etc/sudoers.d/ keep working alongside the directory rules, because nsswitch.conf lists files before sss.

Step 6 - Managing the SSSD cache

SSSD caches users and groups to reduce load on the directory. After changing a user's groups or attributes in LDAP, invalidate the cache so the server sees the change right away:

sudo sss_cache -u jdoe
sudo sss_cache -E

The first command invalidates one user; the second invalidates every cached entry. Neither deletes stored offline credentials. Check what SSSD currently holds for a user:

sudo sssctl user-show jdoe

Joining an Active Directory domain instead

For Active Directory, do not write the LDAP configuration by hand. Use realmd, which joins the domain, creates the Kerberos keytab and writes sssd.conf with the ad provider. The server must resolve the domain's DNS records (use the domain controllers as DNS servers) and have its clock in sync with them.

sudo apt install -y sssd-ad sssd-tools realmd adcli krb5-user
sudo realm discover ad.example.com
sudo realm join -U Administrator ad.example.com

Limit logins to AD groups and enable home directory creation:

sudo realm deny --all
sudo realm permit -g "Linux Admins"
sudo pam-auth-update --enable mkhomedir

Verify with realm list and id [email protected]. By default AD users log in with their fully qualified name; set use_fully_qualified_names = False in the [domain/ad.example.com] section of /etc/sssd/sssd.conf and restart sssd if you prefer short names.

Troubleshooting

getent passwd jdoe returns nothing. Enable detailed logging by adding debug_level = 6 to the [domain/example.com] section, restart with sudo systemctl restart sssd, run the lookup again and read /var/log/sssd/sssd_example.com.log. Most failures are TLS errors (wrong CA, hostname not in the certificate) or a wrong search base.

SSSD does not start after editing the file. Run sudo sssctl config-check and check permissions: the file must be root:root with mode 600. Details are in sudo journalctl -u sssd -n 50 --no-pager.

Password is correct but login is denied. The user is not in a group listed in simple_allow_groups. Confirm group membership with id jdoe, then sudo sss_cache -u jdoe if you just changed it in LDAP.

Group changes are not visible. SSSD is serving cached data. Invalidate the cache with sudo sss_cache -E.

Conclusion

Your Ubuntu 24.04 server now authenticates users against a central LDAP directory through SSSD, creates their home directories on first login, restricts access to approved groups and reads sudo rules from the directory. Repeat the same configuration on other servers, ideally with a configuration management tool such as Ansible. Next, consider storing SSH public keys in LDAP and serving them with sss_ssh_authorizedkeys, or requiring multi-factor authentication for privileged groups.