Authentifier Linux sur un annuaire LDAP avec SSSD

Sur un parc de plusieurs serveurs, créer un compte local par machine et par personne ne tient pas : c'est le rôle d'un annuaire LDAP, et de SSSD pour l'y brancher côté Linux. Une fois SSSD configuré, un utilisateur défini une seule fois dans l'annuaire peut se connecter à tous les serveurs, sans useradd. Ce guide connecte un serveur Linux à un annuaire LDAP avec SSSD : installation, sssd.conf, branchement nsswitch, création automatique du home, et le piège du TLS qui bloque tout le monde une fois. Chaque commande et chaque sortie vient d'un lab réel (Ubuntu 24.04, SSSD 2.9, annuaire OpenLDAP). Public visé : administrateurs gérant plus d'un serveur.

Ce guide couvre un objectif direct LFCS : « configurer un système pour utiliser un service d'authentification existant ». Le vocabulaire des annuaires (DN, OU, attributs) est posé dans LDAP, Active Directory et Kerberos, à lire d'abord si ces termes sont nouveaux.

Ce que vous allez apprendre

Installer SSSD et ses greffons NSS et PAM.
Configurer sssd.conf comme fournisseur d'identité et d'authentification LDAP.
Brancher nsswitch pour que le système voie les comptes de l'annuaire.
Créer le home automatiquement au premier login avec pam_mkhomedir.
Vérifier la résolution (getent, id) et l'authentification (connexion réelle).

Prérequis

Un serveur Linux (ce guide est testé sur Ubuntu 24.04 ; les différences RHEL/AlmaLinux sont signalées).
Un annuaire LDAP joignable, avec des comptes POSIX (attributs uidNumber, gidNumber). Pour monter un annuaire de test rapidement, voir LLDAP, un serveur LDAP léger.
Le base DN de l'annuaire (ici dc=lab,dc=lan) et un accès en lecture aux comptes.
Les droits sudo sur le serveur à configurer.

Comment SSSD s'insère dans Linux

Avant de configurer, il faut comprendre les trois maillons que traverse une demande d'identité. Quand vous tapez id alice, le système ne sait pas d'emblée où chercher : c'est nsswitch qui lui dit « regarde d'abord dans les fichiers locaux, puis dans sss ». La source sss, c'est SSSD, un démon qui interroge l'annuaire LDAP et met en cache les réponses. Pour l'authentification (vérifier un mot de passe), c'est PAM qui appelle pam_sss, lequel demande à SSSD de valider les identifiants auprès de l'annuaire.

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

Retenez cette chaîne : NSS pour l'identité (qui est cette personne ?), PAM pour l'authentification (a-t-elle le bon mot de passe ?). SSSD sert les deux.

Installer SSSD

Les paquets couvrent SSSD lui-même, le connecteur LDAP, les greffons NSS et PAM, et le module qui crée le home.

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

Configurer `sssd.conf`

Tout se joue dans /etc/sssd/sssd.conf. Ce fichier déclare un domaine (au sens SSSD : une source d'identité) et pointe vers l'annuaire.

[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

Les directives qui comptent :

id_provider et auth_provider = ldap : l'annuaire fournit l'identité et l'authentification.
ldap_uri : l'adresse du serveur LDAP (remplacez localhost par le FQDN de votre annuaire).
ldap_search_base : la branche où chercher les comptes, le base DN.
override_homedir et default_shell : imposent un home et un shell même si l'annuaire ne les fournit pas.
cache_credentials = true : autorise la connexion même annuaire injoignable (portable hors ligne), grâce au cache.

Le fichier contient des paramètres sensibles : SSSD refuse de démarrer s'il est lisible par d'autres. Verrouillez-le, c'est obligatoire :

sudo chmod 600 /etc/sssd/sssd.conf

Brancher `nsswitch`

Pour que getent et id interrogent l'annuaire, il faut ajouter la source sss dans /etc/nsswitch.conf. L'installation de libnss-sss le fait souvent déjà ; vérifiez que les trois bases pointent bien vers sss :

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

L'ordre est important : files d'abord. Un compte local (comme root) reste résolu localement ; l'annuaire n'est consulté que pour ce qui n'existe pas en local.

Un compte d'annuaire n'a pas de répertoire personnel sur la machine. Le module pam_mkhomedir le crée à la première connexion. Sur Debian et Ubuntu, on l'active (avec le greffon SSSD) via pam-auth-update :

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

Sur RHEL/AlmaLinux, la commande équivalente branche SSSD et le home en une fois :

sudo authselect select sssd with-mkhomedir --force

Il ne reste qu'à démarrer le démon :

sudo systemctl enable --now sssd

Le piège du TLS

Voici l'erreur qui piège tout le monde au premier essai. L'identité fonctionne, mais l'authentification échoue avec un message opaque :

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

Ce n'est pas un mauvais mot de passe. Par sécurité, SSSD refuse d'envoyer un mot de passe en clair sur une connexion LDAP non chiffrée. Tant que vous n'avez pas de TLS, deux options : configurer LDAPS (recommandé en production), ou, en lab, autoriser explicitement l'envoi en clair avec une directive au nom volontairement dissuasif :

ldap_auth_disable_tls_never_use_in_production = true

Après un sudo systemctl restart sssd, l'authentification passe.

Vérifier la résolution

Le premier test ne touche pas au mot de passe : il vérifie que le système voit le compte de l'annuaire. Sur le lab, l'utilisateur alice n'existe que dans LDAP :

getent passwd alice

alice:*:5001:5000:Alice Martin:/home/alice:/bin/bash

id alice

uid=5001(alice) gid=5000(equipe) groups=5000(equipe)

Ces sorties viennent de l'annuaire, via SSSD : aucun compte alice n'existe dans /etc/passwd. Le groupe suit :

getent group equipe

equipe:*:5000:

Vérifier l'authentification

L'identité résout, reste à prouver qu'alice peut se connecter. Une simple connexion SSH exerce toute la chaîne PAM, SSSD, LDAP :

ssh alice@localhost

CONNECTE utilisateur=alice uid=5001 home=/home/alice

Deux preuves confirment le succès. D'abord le journal d'authentification, qui montre la session ouverte et le home créé :

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

Ensuite le répertoire personnel, créé par pam_mkhomedir au moment du login :

ls -ld /home/alice

drwxr-x--- 3 alice equipe 4096 /home/alice

alice n'a jamais été créée localement, et pourtant elle se connecte avec un home et le bon groupe. C'est tout l'intérêt de la centralisation.

Sécurité et bonnes pratiques

Chiffrez toujours la liaison en production : ldaps:// ou StartTLS avec un certificat de confiance. La directive ldap_auth_disable_tls_never_use_in_production ne quitte pas le lab.
Un compte de service dédié en lecture seule pour le bind SSSD, jamais le compte administrateur de l'annuaire.
Limitez qui peut se connecter avec access_provider = ldap et un filtre, pour qu'un compte de l'annuaire ne donne pas accès à tous les serveurs.
sudo pour les comptes d'annuaire : un groupe LDAP peut être référencé dans /etc/sudoers comme un groupe local (%equipe ALL=(ALL) ALL), à condition qu'il résolve via getent.

Dépannage

Symptôme	Cause probable	Solution
`getent passwd alice` ne renvoie rien	`sss` absent de `nsswitch.conf`	Ajouter `sss` aux lignes passwd/group/shadow
SSSD ne démarre pas	`sssd.conf` lisible par tous	`chmod 600 /etc/sssd/sssd.conf`
`id` marche mais le login échoue (`6 Permission denied`)	Pas de TLS pour l'auth	LDAPS/StartTLS, ou flag TLS-off en lab
Login OK mais « No such file or directory »	`pam_mkhomedir` non activé	`pam-auth-update --enable mkhomedir` ou `authselect ... with-mkhomedir`
Pas de shell (`/usr/sbin/nologin`)	L'annuaire ne fournit pas `loginShell`	`default_shell = /bin/bash` dans `sssd.conf`
Changements ignorés	Cache SSSD obsolète	`sudo sss_cache -E && sudo systemctl restart sssd`

À retenir

nsswitch route l'identité, PAM route l'authentification : SSSD sert les deux via la source sss.
Un compte d'annuaire se connecte à tous les serveurs configurés, sans compte local.
override_homedir et default_shell garantissent un home et un shell même si l'annuaire ne les fournit pas.
pam_mkhomedir crée le répertoire personnel au premier login.
Le piège numéro un : SSSD refuse l'authentification en clair ; il faut TLS, ou le flag explicite en lab.
sssd.conf en chmod 600, sinon le démon refuse de démarrer.

Prochaines étapes

LDAP, Active Directory et Kerberos Les concepts d'annuaire : DN, OU, attributs, tickets Kerberos.

Monter un annuaire avec LLDAP Un serveur LDAP léger pour se constituer un annuaire de test ou de production.

Administrer utilisateurs et groupes Comptes locaux, UID/GID, et cohabitation avec les comptes d'annuaire.

Déléguer avec sudo Donner des droits d'administration, y compris à un groupe d'annuaire.