Joindre un serveur Debian au domaine Active Directory avec realmd et SSSD

Joindre un serveur Linux à un domaine Active Directory, c'est créer son compte d'ordinateur dans l'annuaire et configurer le système pour qu'il reconnaisse les comptes et les groupes du domaine comme des utilisateurs Linux : un administrateur se connecte alors en SSH avec son compte Windows, et ses droits dépendent de ses groupes dans l'annuaire. Sous Debian, realmd réalise la jonction et SSSD assure ensuite l'identification et l'authentification. Ce chapitre explique le rôle de chaque brique, joint srv-glpi au domaine ad.sorbier.example, restreint les connexions à un groupe, donne les droits sudo par groupe et montre comment dépanner.

Pourquoi joindre un serveur Linux au domaine

Sans jonction, chaque serveur Linux a ses propres comptes locaux. Avec dix serveurs et trois administrateurs, cela fait trente comptes à créer, trente mots de passe à changer, et trente comptes à ne pas oublier de supprimer le jour où quelqu'un quitte l'entreprise. Avec la jonction :

• un seul compte par personne, dans l'annuaire, avec la politique de mots de passe du domaine ;
• une désactivation unique : un compte désactivé dans l'annuaire ne peut plus se connecter à aucun serveur ;
• des droits par groupe : être membre de GG_Admins_Linux donne l'accès et sudo sur les serveurs Linux, et rien d'autre ;
• des journaux nominatifs : chaque connexion et chaque sudo portent le nom de la personne, pas « root » ou « admin ».

Chez Sorbier, srv-glpi et srv-partages sont joints au domaine. srv-web, dans la DMZ, ne l'est pas : un serveur exposé à Internet ne doit pas pouvoir parler Kerberos et LDAP aux contrôleurs de domaine, et la matrice des flux du pare-feu l'interdit (cours Cybersécurité des infrastructures, matrice des flux de Sorbier). Il garde des comptes locaux, accessibles seulement par clé SSH depuis le réseau d'administration.

Les briques de la jonction

SSSD calcule l'UID et le GID Linux de chaque compte à partir de son identifiant de sécurité Windows (SID) : le même compte a donc le même UID sur tous les serveurs joints, sans rien stocker dans l'annuaire. C'est l'option ldap_id_mapping = True, activée par défaut avec realmd.

Les prérequis

La plupart des échecs de jonction viennent d'un prérequis oublié. Vérifie-les avant de lancer quoi que ce soit.

1. Le DNS de l'annuaire. Le serveur doit utiliser les contrôleurs comme DNS et trouver leurs enregistrements de service (SRV), qui disent où sont les contrôleurs et les services Kerberos et LDAP :

host -t SRV _ldap._tcp.ad.sorbier.example
# _ldap._tcp.ad.sorbier.example has SRV record 0 100 389 srv-ad.ad.sorbier.example.
# _ldap._tcp.ad.sorbier.example has SRV record 0 100 389 srv-ad2.ad.sorbier.example.
host srv-glpi.ad.sorbier.example
# srv-glpi.ad.sorbier.example has address 192.168.10.184

La commande host est dans le paquet bind9-host, installé avec les outils de base de Debian.

2. L'heure, synchronisée sur les contrôleurs, à moins de 5 minutes (chapitre 1) : chronyc tracking.

3. Le nom complet du serveur : hostname -f doit répondre srv-glpi.ad.sorbier.example. Le nom court devient le nom du compte d'ordinateur (SRV-GLPI$) : 15 caractères au plus, la limite des noms NetBIOS.

4. Les flux vers les contrôleurs. srv-glpi est dans le même VLAN que srv-ad et srv-ad2 : rien à ouvrir sur pfSense. Un serveur placé dans un autre VLAN a besoin de ces flux vers les deux contrôleurs :

5. Un compte autorisé à joindre des ordinateurs à l'OU des serveurs : chez Sorbier, adm1-clambert a reçu cette délégation sur OU=Serveurs,OU=Sorbier,DC=ad,DC=sorbier,DC=example.

Installer les paquets

sudo apt install realmd sssd sssd-tools libnss-sss libpam-sss adcli \
  samba-common-bin oddjob oddjob-mkhomedir packagekit krb5-user

À l'installation de krb5-user, un écran demande le royaume Kerberos par défaut : réponds AD.SORBIER.EXAMPLE, le nom du domaine en majuscules. Laisse vides les deux questions suivantes (serveurs Kerberos et serveur d'administration) : ils seront trouvés par le DNS.

Découvrir puis joindre le domaine

realm discover ad.sorbier.example

ad.sorbier.example
  type: kerberos
  realm-name: AD.SORBIER.EXAMPLE
  domain-name: ad.sorbier.example
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

configured: no : le serveur n'est pas encore membre. Si realm discover ne trouve rien, le problème est le DNS (prérequis 1). La jonction elle-même :

sudo realm join --user=adm1-clambert \
  --computer-ou="OU=Serveurs,OU=Sorbier,DC=ad,DC=sorbier,DC=example" \
  ad.sorbier.example
# Password for adm1-clambert:
realm list
# ad.sorbier.example
#   type: kerberos
#   realm-name: AD.SORBIER.EXAMPLE
#   domain-name: ad.sorbier.example
#   configured: kerberos-member
#   …
#   login-formats: %U@ad.sorbier.example
#   login-policy: allow-realm-logins

En une commande, realm join a créé le compte d'ordinateur SRV-GLPI$ dans l'OU des serveurs, écrit la keytab /etc/krb5.keytab, généré /etc/sssd/sssd.conf, activé SSSD dans NSS et PAM et démarré le service. Sans --computer-ou, l'ordinateur arriverait dans le conteneur Computers, où aucune GPO d'OU ne l'atteint. Côté Windows, vérifie :

Get-ADComputer srv-glpi -Properties OperatingSystem, DistinguishedName |
    Select-Object Name, OperatingSystem, DistinguishedName

Le fichier sssd.conf

realm join a écrit ce fichier :

[sssd]
domains = ad.sorbier.example
config_file_version = 2
services = nss, pam

[domain/ad.sorbier.example]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.SORBIER.EXAMPLE
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = ad.sorbier.example
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Avec un seul domaine, des noms courts sont plus pratiques. Modifie deux lignes :

use_fully_qualified_names = False
fallback_homedir = /home/%u

sudo systemctl restart sssd
sudo sss_cache -E        # vide le cache de SSSD

Le fichier doit rester la propriété de root avec les droits 600, sinon SSSD refuse de démarrer. Avec des noms courts, évite qu'un compte local porte le même nom qu'un compte du domaine : le compte local passerait en premier.

Vérifier que les comptes du domaine sont reconnus

id jlefevre
# uid=1462401107(jlefevre) gid=1462400513(utilisateurs du domaine) groupes=1462400513(utilisateurs du domaine),1462401129(gg_comptables)
getent passwd adm1-clambert
# adm1-clambert:*:1462401215:1462400513:Chloé Lambert (admin T1):/home/adm1-clambert:/bin/bash
kinit adm1-clambert
klist
# Ticket cache: FILE:/tmp/krb5cc_1000
# Default principal: adm1-clambert@AD.SORBIER.EXAMPLE
# Valid starting       Expires              Service principal
# 21/10/2026 10:12:44  21/10/2026 20:12:44  krbtgt/AD.SORBIER.EXAMPLE@AD.SORBIER.EXAMPLE
sudo klist -k | head
# Keytab name: FILE:/etc/krb5.keytab
# KVNO Principal
#    2 SRV-GLPI$@AD.SORBIER.EXAMPLE
#    …

Les noms des groupes apparaissent en minuscules : avec Active Directory, SSSD traite les noms sans tenir compte de la casse et les renvoie en minuscules. Les UID sont de grands nombres, calculés à partir du SID : ils seront les mêmes sur tout autre serveur joint avec SSSD. srv-partages, joint avec winbind au chapitre 9, calcule les siens autrement (10000 + RID) : les deux méthodes ne donnent pas les mêmes identifiants. Les valeurs exactes dépendent de ton domaine.

SSSD renouvelle tout seul le mot de passe du compte d'ordinateur (tous les 30 jours par défaut), comme le fait un poste Windows : rien à planifier.

Créer le dossier personnel à la première connexion

sudo pam-auth-update --enable mkhomedir

Sans cette ligne, la première connexion d'un compte du domaine réussit, mais l'utilisateur arrive dans / avec le message Could not chdir to home directory /home/adm1-clambert: No such file or directory.

Restreindre qui peut se connecter

Par défaut (login-policy: allow-realm-logins), tout compte du domaine peut ouvrir une session sur le serveur, y compris les comptables et les stagiaires. Sur un serveur, seuls les administrateurs Linux doivent pouvoir le faire :

sudo realm deny --all
sudo realm permit -g GG_Admins_Linux

realmd remplace alors, dans sssd.conf, access_provider = ad par :

access_provider = simple
simple_allow_groups = GG_Admins_Linux

Désormais, un compte qui n'est pas membre de GG_Admins_Linux est refusé, même avec le bon mot de passe ; le journal journalctl -u ssh affiche pam_sss(sshd:account): Access denied for user jlefevre: 6 (Permission denied).

Donner les droits d'administration à un groupe du domaine

Les membres de GG_Admins_Linux doivent pouvoir utiliser sudo. Crée le fichier avec visudo, qui vérifie la syntaxe avant d'enregistrer :

sudo visudo -f /etc/sudoers.d/gg_admins_linux

%gg_admins_linux ALL=(ALL:ALL) ALL

sudo visudo -c
# /etc/sudoers: parsed OK
# /etc/sudoers.d/gg_admins_linux: parsed OK

Le nom du groupe est écrit en minuscules, comme SSSD le renvoie. Chaque sudo est journalisé avec le nom de la personne (sudo: adm1-clambert : TTY=pts/0 ; PWD=/home/adm1-clambert ; USER=root ; COMMAND=/usr/bin/systemctl reload nginx) : ce journal partira vers le serveur central (chapitre 12).

Se connecter avec un compte du domaine

ssh adm1-clambert@srv-glpi.ad.sorbier.example

La connexion se fait avec le mot de passe du domaine. Elle n'est possible que depuis le réseau d'administration (filtrage du pare-feu et, au chapitre 13, du pare-feu local), et le bastion de Sorbier y ajoute l'authentification multifacteur (cours Cybersécurité des infrastructures, administration sécurisée). Les comptes locaux de secours, eux, ne se connectent que par clé.

Dépanner une jonction

Pour en savoir plus, augmente le niveau de détail des journaux de SSSD : ajoute debug_level = 6 dans la section [domain/ad.sorbier.example], redémarre SSSD, reproduis le problème et lis /var/log/sssd/sssd_ad.sorbier.example.log. Remets ensuite le niveau par défaut : à ce niveau, les journaux grossissent vite.

Pour sortir un serveur du domaine (avant de le supprimer ou de le renommer) : sudo realm leave ad.sorbier.example, puis supprime son compte d'ordinateur dans l'annuaire s'il y reste.

Et sans Active Directory ?

Dans une organisation sans Windows, l'annuaire est un serveur LDAP : OpenLDAP, 389 Directory Server, ou FreeIPA (qui ajoute Kerberos, un DNS et une autorité de certification). SSSD s'y connecte de la même façon, avec id_provider = ldap (ou ipa) au lieu de ad. Le fonctionnement de LDAP, de Kerberos et d'Active Directory est expliqué dans le cours Authentification. Pour un serveur de fichiers Samba membre du domaine, la brique d'identification n'est pas SSSD mais winbind (chapitre 9).

Exercices

sudo realm permit -g GG_Support_N2
sudo visudo -f /etc/sudoers.d/gg_support_n2

%gg_support_n2 ALL=(root) /usr/bin/systemctl reload nginx, /usr/bin/systemctl reload php8.4-fpm, /usr/bin/journalctl

Attention aux programmes qu'on autorise par sudo : beaucoup permettent de lancer un shell, qui serait alors un shell root (sudo less, sudo vim, sudo find, sudo tar…). journalctl est sûr sur ce point : lancé par sudo, il ouvre son afficheur en « mode sécurisé », qui interdit d'en sortir vers un shell. Avant d'autoriser une commande, demande-toi toujours si elle peut lancer un autre programme ou écrire n'importe où.