Intégration de SLES 15 Active Directory avec SSSD : Guide étape par étape

Pour un serveur SUSE Linux Enterprise Server 15 standard nécessitant l'authentification des utilisateurs du domaine, SUSE recommande YaST User Logon Management avec SSSD comme solution optimale dans la plupart des environnements Active Directory. SSSD assure l'identité Linux et l'authentification PAM, tandis qu'Active Directory reste la source des comptes et de l'authentification Kerberos. Winbind est plus adapté si votre architecture repose sur la prise en charge de NTLM ou des relations d'approbation entre forêts. Si vous privilégiez l'automatisation, SUSE propose également l'utilisation de Winbind pour la jonction à un realmddomaine ; cet outil de découverte et d'appartenance à un domaine nécessite de vérifier le logiciel client et la stratégie d'accès configurés par votre système avant de l'utiliser à grande échelle.

Cette procédure pas à pas suit le guide de sécurité et de renforcement de SLES 15 SP7, consulté le 6 octobre 2026. Les Service Packs SUSE peuvent différer ; les instructions ci-dessous constituent une procédure basée sur la documentation et ne garantissent pas que les commandes ont été exécutées sur votre domaine. Remplacez les noms de domaine et d’hôte d’exemple par ceux de votre environnement. Effectuez d’abord un test sur une machine SLES non critique et assurez-vous de disposer d’un compte administrateur local en cas de mauvaise configuration de l’authentification du domaine.

Choisissez la méthode d'intégration qui convient à la tâche.

SUSE décrit l'option YaST, basée sur SSSD, comme adaptée à la plupart des jonctions Active Directory et recommande Winbind pour les cas nécessitant NTLM ou des approbations inter-forêts. Il s'agit de points de départ pratiques, mais non d'un substitut aux tests nécessaires pour répondre aux besoins spécifiques de l'application, tels que le partage de fichiers Samba, les règles sudo, la recherche de clés SSH ou la gestion des conflits de noms de domaine. Pour un parc de machines virtuelles Linux standard, privilégiez SSSD, sauf indication contraire dans la documentation.

Que préparer avant de joindre SLES à Active Directory ?

• Un nom d'hôte stable : choisissez le nom d'hôte complet prévu et assurez-vous qu'il est résolu de manière cohérente sur votre réseau et dans Active Directory. Coordonnez toute convention d'appellation des comptes d'ordinateur avec l'équipe d'annuaire.
• DNS compatible avec Active Directory : le client SLES doit interroger un serveur DNS capable de résoudre la zone Active Directory et ses enregistrements de service (SRV). L’utilisation d’un résolveur public seul provoque généralement l’échec de la découverte du domaine.
• Synchronisation horaire : Kerberos nécessite une synchronisation précise des horloges du client et des contrôleurs de domaine. Vérifiez la synchronisation NTP avant de résoudre les problèmes de mots de passe ou de SSSD.
• Accès réseau aux contrôleurs de domaine : vérifiez que le pare-feu et le routage autorisent les protocoles et les ports requis par l’architecture Active Directory de votre organisation, notamment DNS, Kerberos, LDAP et tout trafic nécessaire au catalogue global ou à la modification des mots de passe. N’ouvrez pas tous les ports de manière générale ; demandez à l’administrateur réseau/Active Directory de vous fournir les règles approuvées.
• Identité d'inscription autorisée : utilisez un compte autorisé à ajouter ou à réutiliser des objets ordinateur dans l'unité organisationnelle appropriée. Évitez l'utilisation systématique d'un compte à privilèges élevés lorsque des droits d'adhésion délégués sont disponibles.
• Accès de récupération : Conservez un compte d’administrateur local testé et un moyen d’accéder à la console. Ne définissez pas le domaine comme unique voie d’accès au serveur avant d’avoir validé le nouveau chemin de connexion.

SUSE insiste sur l'importance d'un DNS accessible depuis Active Directory et d'une heure précise pour Kerberos. Son guide indique qu'un domaine se terminant par .example .localpeut entrer en conflit avec le DNS multicast dans certains cas d'intégration. Si votre Active Directory utilise ce suffixe, vérifiez les conséquences sur votre version de SLES et votre configuration réseau auprès de l'administrateur réseau avant de modifier les paramètres de nommage ou de résolution.

hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com

Cette hostcommande peut nécessiter le paquet d'utilitaires DNS sur une installation minimale. Ces vérifications ne garantissent pas que tous les chemins de pare-feu requis sont ouverts ; elles permettent de détecter les problèmes courants de résolution de noms et d'horloge avant l'inscription.

Rejoignez le domaine en utilisant YaST et SSSD.

1. Configurez le résolveur. Ouvrez YaST et sélectionnez Paramètres réseau , puis Nom d'hôte/DNS . Configurez le serveur DNS Active Directory ou un résolveur interne qui redirige correctement la zone Active Directory. Enregistrez les modifications et vérifiez que l'hôte peut résoudre le contrôleur de domaine et les enregistrements de service Active Directory.
2. Ouvrez la Gestion des connexions utilisateur. Dans la fenêtre principale de YaST, lancez Gestion des connexions utilisateur et sélectionnez Modifier les paramètres . Il s'agit du module d'authentification SSSD décrit dans le guide SLES 15 SP7 ; il diffère du module d'appartenance au domaine Windows , qui utilise Winbind.
3. Ajoutez le domaine AD. Cliquez sur Ajouter un domaine , saisissez le nom de domaine DNS (par exemple corp.example.com, `example.com`) et sélectionnez Microsoft Active Directory pour les données d'identité et l'authentification. Assurez-vous que le domaine est activé. Si la découverte automatique DNS n'est pas appropriée sur votre réseau, spécifiez les noms d'hôtes des contrôleurs de domaine approuvés, comme indiqué dans le guide.
4. Vérifiez le nom de la machine et le résultat de la détection. Comparez le nom d'hôte local avec le nom d'ordinateur attendu dans Active Directory. Corrigez toute incohérence avant l'inscription. YaST devrait détecter un serveur Active Directory et indiquer que le client n'est pas encore inscrit. En cas d'échec de la détection, vérifiez à nouveau le DNS, l'heure, le routage et le pare-feu plutôt que d'essayer différents fournisseurs d'authentification.
5. Inscrivez-vous avec un compte autorisé. Saisissez les identifiants AD autorisés à se connecter à la machine. YaST peut installer les logiciels manquants pendant ce processus. Une boîte de dialogue peut proposer une option pour remplacer la configuration Samba ; activez-la uniquement si cette modification concerne votre configuration Samba/AD, et conservez d’abord la configuration existante si les services Samba sont déjà utilisés.
6. Activez le comportement de connexion souhaité. Dans la section « Gérer l'ouverture de session des utilisateurs du domaine » , activez l'ouverture de session des utilisateurs du domaine uniquement après avoir déterminé les comptes qui y auront accès. Configurez la création de répertoires personnels locaux si nécessaire. SUSE documente les fallback_homediroptions override_homedircorrespondantes et présente /home/%uun exemple de format possible. Dans un environnement multi-domaines, définissez un chemin d'accès unique et consultez le manuel SSSD avant de vous fier uniquement à un nom d'utilisateur court.
7. Enregistrez, vérifiez et testez avec un utilisateur sans privilèges. Appliquez les paramètres, assurez-vous que le domaine et les options choisies sont corrects, puis testez avec un compte de domaine standard sur la console ou via le service d'authentification que vous prévoyez d'utiliser. Ne testez pas uniquement avec le compte qui a rejoint la machine.

Comment vérifier la connexion SSSD ?

Vérifiez que SSSD est actif, que NSS peut résoudre une identité de domaine connue et qu'une connexion réelle réussit. Après la connexion de l'utilisateur de test, vérifiez la présence d'un ticket Kerberos. SUSE inclut ces vérifications klistdans getent passwdses contrôles de connexion.

systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist

La chaîne d'identification exacte dépend des paramètres d'appellation SSSD ; certains environnements utilisent DOMAIN\userun nom de type UPN plutôt qu'un nom de type nom d'utilisateur principal (UPN). Si getentaucune entrée n'est retournée, vérifiez que vous interrogez le format de nom et le domaine configurés, puis consultez les journaux du service :

sudo journalctl -u sssd --since "15 minutes ago"

Une recherche réussie ne suffit pas à prouver que l'utilisateur peut se connecter, et un ticket Kerberos existant ne garantit pas que chaque application utilise la pile PAM prévue. Testez une nouvelle session, un changement de mot de passe si nécessaire, l'autorisation par groupe et le chemin de connexion SSH ou bureau approprié. Vérifiez que l'accès est limité aux personnes autorisées.

SSSD ou Winbind : quel compromis est le plus important ?

Pour la plupart des clients SLES nécessitant une authentification Active Directory et des connexions interactives, SSSD est la solution la plus simple et recommandée par le guide de gestion des connexions utilisateur de SUSE. Il intègre la recherche d'identité et l'authentification PAM et peut mettre en cache les informations pour assurer la continuité de service en cas d'indisponibilité temporaire de l'annuaire. L'accès mis en cache présente toutefois des limites : une première connexion ne peut pas s'appuyer sur des informations d'identification mises en cache, et l'accès aux ressources de l'annuaire ou la modification des mots de passe nécessitent toujours un contrôleur de domaine accessible. Il est donc recommandé de définir et de tester votre politique de connexion hors ligne plutôt que de considérer la mise en cache comme une solution complète en cas de panne d'Active Directory.

Choisissez Winbind lorsque l'intégration de domaine Samba, NTLM ou les approbations inter-forêts sont requises. Il ne s'agit pas d'une simple alternative à SSSD : chaque chemin utilise des démons et des composants NSS/PAM différents. Documentez le service responsable des recherches de domaine et des connexions, et évitez de mélanger les anciennes modifications manuelles PAM/NSS avec les paramètres gérés par YaST.

Utilisez cette méthode realmdlorsqu'un flux de travail shell reproductible est essentiel. Le guide d'administration du stockage SLES 15 SP7 de SUSE documente realm discover --verbosela découverte DNS, realm join --verbosel'inscription et realm permitles autorisations de connexion. Vérifiez le logiciel client sélectionné et la configuration SSSD générée pour votre déploiement. Évitez d'autoriser un accès généralisé (« autoriser tout le monde ») en production, sauf si cela fait partie d'une politique explicite.

Pannes courantes et prochain contrôle

• La découverte de domaine ne renvoie rien : vérifiez le serveur DNS du client et l’enregistrement SRV AD, puis confirmez que l’hôte peut atteindre les contrôleurs de domaine répertoriés.
• Erreurs Kerberos malgré un mot de passe correct : vérifiez la synchronisation de l’heure système, le nom DNS utilisé pour le contrôleur de domaine et assurez-vous que le compte d’ordinateur est activé et correctement nommé.
• L'utilisateur résout le problème mais ne peut pas se connecter : vérifiez que la connexion au domaine est activée dans YaST, contrôlez les restrictions d'accès et l'état du compte dans AD et consultez les journaux SSSD/PAM.
• La connexion fonctionne, mais le répertoire personnel est manquant : vérifiez que la création du répertoire personnel est activée et que le chemin configuré est valide et unique pour l’utilisateur.
• L'opération d'intégration échoue après des tentatives précédentes : vérifiez la présence d'objets ordinateur obsolètes, de noms d'hôtes dupliqués, de configurations Winbind ou NSS/PAM manuelles résiduelles et de mots de passe machine incompatibles. Avant de supprimer un objet ordinateur ou d'effacer les données SSSD locales, veuillez coordonner le nettoyage avec l'administrateur Active Directory.

Quand faut-il s'arrêter et choisir une approche différente ?

Avant le déploiement, veuillez interrompre l'opération si votre environnement repose sur des relations d'approbation inter-forêts, NTLM, un serveur Samba, plusieurs forêts avec des noms d'utilisateur courts similaires ou des règles d'accès complexes non prises en charge par les paramètres de base de YaST. Ces conditions peuvent modifier le fournisseur préféré ou nécessiter une configuration SSSD supplémentaire. Testez-les avec des comptes représentatifs et des services réels dans un environnement de test et conservez l'identifiant de récupération jusqu'à ce que la stratégie soit validée.

En résumé : pour un poste de travail ou un serveur SLES 15 SP7 standard nécessitant des identités et des connexions Active Directory, commencez par la gestion des connexions utilisateur YaST avec SSSD. Configurez d’abord correctement le DNS, l’heure, le nommage des hôtes et les permissions d’intégration ; puis vérifiez la résolution de noms, Kerberos, l’authentification PAM et le périmètre d’accès. Sélectionnez Winbind pour les exigences spécifiques Samba, NTLM ou inter-forêts identifiées par SUSE, et utilisez-le realmdlorsque son interface en ligne de commande correspond mieux à votre processus opérationnel.

Sources : Guide de sécurité et de renforcement de SUSE SLES 15 SP7 : prise en charge d’Active Directory ; Guide d’administration du stockage de SUSE SLES 15 SP7 : realmd ; SUSE SLES 15 SP7 : clients d’authentification et SSSD ; Notes de version de SUSE SLES 15 SP7 .