Intégration Linux dans Active Directory : Winbind, SSSD et GPO pour Linux en 2026

Pourquoi intégrer Linux dans Active Directory ?

Dans les environnements d'entreprise hybrides, les serveurs Linux doivent s'authentifier contre le même annuaire que les postes Windows. Les raisons sont multiples : centralisation des comptes, SSO Kerberos, audit des accès, conformité (NIS2, ISO 27001 A.9.2), et surtout éviter la prolifération de comptes locaux non gérés.

Deux composants permettent cette intégration :

• Winbind (Samba) — l'approche historique, requise pour les partages SMB et les trusts inter-forêts
• SSSD + adcli — l'approche moderne recommandée par Red Hat, Canonical et la communauté

Prérequis communs

Avant toute configuration, vérifiez :

# 1. Résolution DNS vers les DC
dig -t SRV _ldap._tcp.DOMAINE.LOCAL
# Doit retourner les enregistrements SRV des DC

# 2. Synchronisation NTP — critique pour Kerberos (max 5 min de dérive)
timedatectl status
# Configurer si nécessaire :
timedatectl set-ntp true

# 3. Hostname FQDN correct
hostnamectl set-hostname serveur.domaine.local
grep -v "127.0.1.1" /etc/hosts  # Supprimer les entrées qui pourraient interférer

Approche 1 — Winbind / Samba (méthode classique)

Installation

# Debian/Ubuntu
apt install -y samba winbind krb5-user libpam-winbind libnss-winbind

# RHEL/AlmaLinux/Rocky
dnf install -y samba samba-winbind samba-winbind-clients krb5-workstation

Configuration Kerberos

# /etc/krb5.conf
[libdefaults]
    default_realm = DOMAINE.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = true

[realms]
    DOMAINE.LOCAL = {
        kdc = dc01.domaine.local
        admin_server = dc01.domaine.local
    }

[domain_realm]
    .domaine.local = DOMAINE.LOCAL
    domaine.local = DOMAINE.LOCAL

Configuration Samba

# /etc/samba/smb.conf
[global]
    workgroup = DOMAINE
    realm = DOMAINE.LOCAL
    security = ADS
    kerberos method = secrets and keytab

    # Mappage UID/GID — utiliser idmap rid pour la cohérence
    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config DOMAINE : backend = rid
    idmap config DOMAINE : range = 20000-99999

    winbind use default domain = yes
    winbind offline logon = yes
    winbind refresh tickets = yes
    winbind enum users = yes
    winbind enum groups = yes

    template homedir = /home/%U
    template shell = /bin/bash

Jonction au domaine

# Jonction
net ads join -U administrateur@DOMAINE.LOCAL

# Vérification
net ads testjoin
# Retourne : Join is OK

# Démarrer winbind
systemctl enable --now winbind

# Tester la résolution des utilisateurs AD
wbinfo -u | head -10
wbinfo -g | head -10
getent passwd DOMAINE\utilisateur

NSS et PAM pour Winbind

# /etc/nsswitch.conf — ajouter winbind
passwd:     files winbind
group:      files winbind
shadow:     files

# PAM — activer l'auth Winbind
pam-auth-update --enable winbind  # Debian/Ubuntu
authconfig --enablewinbind --update  # RHEL (legacy)
# ou sur RHEL 8+ :
authselect select winbind --force

Approche 2 — SSSD + adcli (méthode moderne)

SSSD (System Security Services Daemon) s'authentifie via Kerberos et récupère les infos utilisateur via LDAP. C'est l'approche recommandée depuis RHEL 7 / Ubuntu 20.04.

Installation

# Debian/Ubuntu
apt install -y sssd sssd-ad sssd-tools adcli oddjob-mkhomedir krb5-user

# RHEL/AlmaLinux/Rocky
dnf install -y sssd sssd-ad adcli oddjob oddjob-mkhomedir krb5-workstation realmd

Jonction avec realm (recommandé)

# Découverte du domaine
realm discover DOMAINE.LOCAL

# Jonction — realm configure tout automatiquement
realm join --user=administrateur DOMAINE.LOCAL

# Vérification
realm list
# Doit afficher : configured: kerberos-member

Configuration SSSD fine-tuning

# /etc/sssd/sssd.conf (mode 600, owner root)
[sssd]
domains = domaine.local
config_file_version = 2
services = nss, pam, ssh

[domain/domaine.local]
ad_domain = domaine.local
krb5_realm = DOMAINE.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False  # permet "user" au lieu de "user@domaine.local"
fallback_homedir = /home/%u
access_provider = ad

# GPO access control (voir section suivante)
ad_gpo_access_control = enforcing
ad_gpo_map_interactive = +xdm-greeter

chmod 600 /etc/sssd/sssd.conf
systemctl restart sssd

# Test
id utilisateur_ad
ssh utilisateur_ad@localhost

GPO pour Linux — Ce qui fonctionne réellement en 2026

C'est le point le plus mal documenté et le plus souvent mal compris. Voici l'état exact du support GPO sur Linux.

Ce que SSSD peut appliquer (support natif)

SSSD implémente le GPO-based access control — il lit les GPOs depuis les DC et applique les Windows Logon Rights via PAM. Concrètement, SSSD supporte ces paramètres GPO :

Configuration GPO côté Windows (Active Directory)

# Sur le DC — créer une GPO pour contrôler l'accès SSH aux serveurs Linux
# Computer Configuration > Windows Settings > Security Settings >
# Local Policies > User Rights Assignment >
# "Allow log on through Remote Desktop Services"
# → Ajouter : "Admins-Linux", "SG-Ops"

# Appliquer la GPO à l'OU contenant les comptes machines Linux
# Les comptes machines Linux sont visibles dans AD après jonction

Configuration SSSD côté Linux

# /etc/sssd/sssd.conf — section [domain/...]

# Mode enforcing : les GPOs sont appliquées
ad_gpo_access_control = enforcing

# Mode permissive : log seulement (pour tester avant de passer en enforcing)
# ad_gpo_access_control = permissive

# Ajouter SSH au mapping remote_interactive si non présent
ad_gpo_map_remote_interactive = +sshd

# Ajouter sudo au mapping interactive
ad_gpo_map_interactive = +sudo

# Journalisation pour debug
ad_gpo_cache_timeout = 5  # secondes, pour les tests

# Vérifier les GPOs appliquées à ce système
sssctl domain-status domaine.local
sssctl logs-fetch /tmp/sssd-debug.log

# Si un utilisateur ne peut pas se connecter alors qu'il devrait :
journalctl -u sssd | grep -i gpo | tail -20

Ce que GPO ne peut PAS faire sur Linux (limites réelles)

Contrairement à Windows, SSSD n'applique pas :

• Les paramètres de registre Windows (scripts de démarrage, politiques logicielles)
• Les politiques AppLocker ou WDAC
• La redistribution de sudoers via GPO (nécessite AD Bridge ou PBIS)
• Les politiques de mot de passe locaux Linux
• Le déploiement de logiciels ou de fichiers de configuration arbitraires
• Les scripts de connexion GPO (.bat/.ps1)

Pour ces cas, les alternatives sont :

• Ansible/Puppet/Chef — gestion de configuration centralisée
• Microsoft Intune — support Linux (Ubuntu 20.04+, RHEL 8+) pour les politiques de conformité et quelques profils de configuration via MDM
• Centrify / BeyondTrust AD Bridge / PBIS — solutions commerciales étendant les GPOs natifs à Linux

Sudo via Active Directory (sans outil tiers)

Une configuration fréquente : gérer les droits sudo des utilisateurs AD depuis LDAP, sans GPO.

# Activer le provider sudoers SSSD
# /etc/sssd/sssd.conf — ajouter :
services = nss, pam, sudo

[domain/domaine.local]
sudo_provider = ad  # ou ldap

# Créer l'OU sudoers dans AD (schéma sudo) :
# OU=sudoers,DC=domaine,DC=local
# Objet : cn=Admins-Linux, objectClass=sudoRole
#   sudoUser: %admins-linux
#   sudoHost: ALL
#   sudoCommand: ALL

# /etc/sudoers.d/sssd-ad
%admins-linux ALL=(ALL) ALL

# Tester
sudo -l -U utilisateur_ad
# Doit afficher les règles remontées d'AD

Sécurisation de l'intégration

Compte de service dédié et droits minimaux

# Jointure avec un compte de service dédié (pas l'administrateur du domaine)
# Sur AD : déléguer uniquement "Join computer to domain" sur l'OU cible
realm join --user=svc-linux-join@domaine.local            --computer-ou="OU=Serveurs-Linux,DC=domaine,DC=local"            DOMAINE.LOCAL

Restreindre les groupes autorisés à se connecter

# Via realm — restreindre à certains groupes AD
realm permit --groups "admins-linux" "ops-team"

# Cela modifie sssd.conf :
# simple_allow_groups = admins-linux, ops-team
# access_provider = simple

Rotation automatique du compte machine

# adcli renouvelle automatiquement le mot de passe du compte machine
# Configurer dans sssd.conf :
ad_machine_account_password_renewal_opts = 0:1440  # vérif toutes les 24h

# Vérifier l'état
adcli info domaine.local

Audit des connexions AD sur Linux

# Activer l'audit PAM dans /etc/pam.d/common-session (ou sshd)
session required pam_loginuid.so

# Avec auditd — tracer les connexions d'utilisateurs AD
auditctl -a always,exit -F arch=b64 -S execve -F uid>=20000 -k ad-user-exec
# UID 20000+ = plage SSSD/Winbind pour les utilisateurs AD

Winbind vs SSSD — Quand choisir quoi

Dépannage rapide

# SSSD ne démarre pas
journalctl -u sssd -n 50
sssctl config-check

# Utilisateur AD non trouvé
sssctl user-checks utilisateur@domaine.local
id utilisateur@domaine.local

# Problème Kerberos
klist -k /etc/krb5.keytab  # vérifier le keytab
kinit -k -t /etc/krb5.keytab host/serveur.domaine.local

# GPO bloque les connexions — passer temporairement en permissive
# sssd.conf : ad_gpo_access_control = permissive
# systemctl restart sssd

# Winbind — DC non joignable
net ads info
wbinfo --ping-dc

Conclusion

En 2026, l'intégration Linux/Active Directory a atteint une maturité réelle avec SSSD. Le support natif des GPOs de contrôle d'accès est fonctionnel et suffisant pour la majorité des besoins : qui peut se connecter, sur quels systèmes, via quel protocole. Ce n'est pas l'équivalent complet des GPOs Windows, mais c'est ce qui fonctionne sans outil commercial.

Pour aller plus loin côté conformité, la checklist de durcissement Active Directory couvre les 83 contrôles essentiels — dont la sécurisation des comptes machines Linux dans l'annuaire.