Skip to content
Stéphane Robert
Français
Account: not signed in, sync available My learning
Select theme
Français
Lire en français

Authenticate Linux against an LDAP directory with SSSD

By updated

Improve this page

What would you like to report?

The issue opens pre-filled with this page title and URL.

On a fleet of several servers, creating a local account per machine and per person does not scale: that is the role of an LDAP directory, and of SSSD to plug it in on the Linux side. Once SSSD is configured, a user defined only once in the directory can log in to every server, with no useradd. This guide connects a Linux server to an LDAP directory with SSSD: installation, sssd.conf, nsswitch wiring, automatic home creation, and the TLS trap that catches everybody once. Every command and output comes from a real lab (Ubuntu 24.04, SSSD 2.9, OpenLDAP directory). Audience: administrators managing more than one server.

This guide covers a direct LFCS objective: "Configure the system to use LDAP user and group accounts". The directory vocabulary (DN, OU, attributes) is laid out in LDAP, Active Directory and Kerberos (in French), to read first if these terms are new.

What you will learn

  • Install SSSD and its NSS and PAM plugins.
  • Configure sssd.conf as the LDAP identity and authentication provider.
  • Wire nsswitch so that the system sees the directory's accounts.
  • Create the home automatically at first login with pam_mkhomedir.
  • Check resolution (getent, id) and authentication (real login).

Prerequisites

  • A Linux server (this guide is tested on Ubuntu 24.04; RHEL/AlmaLinux differences are flagged).
  • A reachable LDAP directory, with POSIX accounts (uidNumber, gidNumber attributes). To set up a test directory quickly, see LLDAP (in French), a lightweight LDAP server.
  • The directory's base DN (here dc=lab,dc=lan) and read access to the accounts.
  • sudo rights on the server to configure.

How SSSD fits into Linux

Before configuring, you must understand the three links an identity request goes through. When you type id alice, the system does not know right away where to look: it is nsswitch that tells it "look first in the local files, then in sss". The sss source is SSSD, a daemon that queries the LDAP directory and caches the answers. For authentication (checking a password), it is PAM that calls pam_sss, which asks SSSD to validate the credentials against the directory.

getent / id        login / ssh
     |                  |
  nsswitch            PAM (pam_sss)
     |                  |
     +------- SSSD -----+   (local cache)
              |
           LDAP (directory)

Remember this chain: NSS for identity (who is this person?), PAM for authentication (do they have the right password?). SSSD serves both.

Install SSSD

The packages cover SSSD itself, the LDAP connector, the NSS and PAM plugins, and the module that creates the home.

Terminal window
sudo apt install sssd sssd-ldap libnss-sss libpam-sss oddjob-mkhomedir

Configure sssd.conf

Everything happens in /etc/sssd/sssd.conf. This file declares a domain (in SSSD's sense: an identity source) and points to the directory.

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


[domain/LAB]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=lab,dc=lan
override_homedir = /home/%u
default_shell = /bin/bash
cache_credentials = true
enumerate = true

The directives that matter:

  • id_provider and auth_provider = ldap: the directory provides identity and authentication.
  • ldap_uri: the address of the LDAP server (replace localhost with your directory's FQDN).
  • ldap_search_base: the branch where to look for accounts, the base DN.
  • override_homedir and default_shell: impose a home and a shell even if the directory does not provide them.
  • cache_credentials = true: allows login even with the directory unreachable (offline laptop), thanks to the cache.

Wire nsswitch

For getent and id to query the directory, you must add the sss source in /etc/nsswitch.conf. Installing libnss-sss often does it already; check that the three databases point to sss:

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

The order matters: files first. A local account (such as root) stays resolved locally; the directory is only consulted for what does not exist locally.

Create the home at first login

A directory account has no home directory on the machine. The pam_mkhomedir module creates it at first login. On Debian and Ubuntu, you enable it (along with the SSSD plugin) via pam-auth-update:

Terminal window
sudo pam-auth-update --enable mkhomedir --enable sss

On RHEL/AlmaLinux, the equivalent command wires SSSD and the home in one go:

Terminal window
sudo authselect select sssd with-mkhomedir --force

All that remains is to start the daemon:

Terminal window
sudo systemctl enable --now sssd

The TLS trap

Here is the error that catches everybody on the first try on SSSD 2.9 (Ubuntu 24.04). Identity works, but authentication fails with an opaque message:

pam_sss(sshd:auth): authentication failure ... user=alice
pam_sss(sshd:auth): received for user alice: 6 (Permission denied)

It is not a wrong password. For security, SSSD refuses to send a password in clear text on an unencrypted LDAP connection. As long as you do not have TLS, two options: configure LDAPS (recommended in production), or, in a lab, explicitly allow sending in clear text with a directive whose name is deliberately dissuasive:

ldap_auth_disable_tls_never_use_in_production = true

On a version that still accepts it, such as the lab's Ubuntu 2.9, the directive remains a workaround and not a solution: its name says so.

After a sudo systemctl restart sssd, authentication goes through.

Check resolution

The first test does not touch the password: it checks that the system sees the directory account. On the lab, the user alice exists only in LDAP:

Terminal window
getent passwd alice
alice:*:5001:5000:Alice Martin:/home/alice:/bin/bash
Terminal window
id alice
uid=5001(alice) gid=5000(equipe) groups=5000(equipe)

These outputs come from the directory, via SSSD: no alice account exists in /etc/passwd. The group follows:

Terminal window
getent group equipe
equipe:*:5000:

Check authentication

Identity resolves, it remains to prove that alice can log in. A simple SSH connection exercises the whole PAM, SSSD, LDAP chain:

Terminal window
ssh alice@localhost
CONNECTE utilisateur=alice uid=5001 home=/home/alice

Two proofs confirm the success. First the authentication log, which shows the session opened and the home created:

sshd: Accepted password for alice from ::1 port 49640 ssh2
pam_unix(sshd:session): session opened for user alice(uid=5001)

Then the home directory, created by pam_mkhomedir at login time:

Terminal window
ls -ld /home/alice
drwxr-x--- 3 alice equipe 4096 /home/alice

alice was never created locally, and yet she logs in with a home and the right group. That is the whole point of centralisation.

Security and good practices

A server plugged into a directory delegates its passwords to the network. Two risks appear at once: the link can be eavesdropped, and a valid directory account opens every server configured this way by default. The four points below answer these two risks; the first two are blocking for going into production.

  • Always encrypt the link in production: ldaps:// or StartTLS with a trusted certificate. The ldap_auth_disable_tls_never_use_in_production directive never leaves the lab.
  • A dedicated read-only service account for the SSSD bind, never the directory's administrator account.
  • Limit who can log in with access_provider = ldap and a filter, so that a directory account does not give access to every server.
  • sudo for directory accounts: an LDAP group can be referenced in /etc/sudoers like a local group (%equipe ALL=(ALL) ALL), provided it resolves through getent.

Troubleshooting

SSSD failures fall into two families you must tell apart before searching. If getent passwd alice returns nothing, the problem is in identity resolution: nsswitch.conf or the link to the directory. If getent answers but the login fails, the problem is in authentication: TLS, PAM or shell. This reflex keeps you from editing sssd.conf at random.

SymptomLikely causeFix
getent passwd alice returns nothingsss missing from nsswitch.confAdd sss to the passwd/group/shadow lines
SSSD does not startsssd.conf readable by everyonechmod 600 /etc/sssd/sssd.conf
id works but login fails (6 Permission denied)No TLS for auth (SSSD 2.9)LDAPS/StartTLS, or TLS-off flag in a lab on versions that accept it
Login OK but "No such file or directory"pam_mkhomedir not enabledpam-auth-update --enable mkhomedir or authselect ... with-mkhomedir
No shell (/usr/sbin/nologin)The directory does not provide loginShelldefault_shell = /bin/bash in sssd.conf
Changes ignoredStale SSSD cachesudo sss_cache -E && sudo systemctl restart sssd

Put it into practice

The nsswitch, PAM, SSSD chain only becomes clear once built end to end. The lab has you plug a server into a real LDAP directory, get past the TLS trap, then prove the login of an account that exists in no /etc/passwd.

Key points

  • nsswitch routes identity, PAM routes authentication: SSSD serves both through the sss source.
  • A directory account logs in to every configured server, without a local account.
  • override_homedir and default_shell guarantee a home and a shell even if the directory does not provide them.
  • pam_mkhomedir creates the home directory at first login.
  • The number one trap on SSSD 2.9: clear-text authentication is refused; you need TLS, or the explicit flag in a lab. On SSSD 2.12, the flag no longer exists: check with sssctl config-check.
  • sssd.conf as chmod 600, otherwise the daemon refuses to start.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions
6 min
70% to pass

How it works

  • The timer starts when you click Start
  • Multiple choice, true/false and short answer questions
  • You can move between questions
  • Detailed results are shown at the end

Is this project useful to you?

The guides, courses, quizzes and labs stay free. If you use them regularly, you can contribute to their upkeep and development.

Become a supporting member (new tab) One-time support (new tab) Learn more

Follow the project on LinkedIn