Accueil
» Comment faire
»
Intégrer SLES 15 à Active Directory avec SSSD dans YaST
Intégrer SLES 15 à Active Directory avec SSSD dans YaST
Pour un poste de travail ou un serveur SLES 15 standard nécessitant des utilisateurs et des connexions basés sur Active Directory, utilisez User Logon Managementle module YaST et sélectionnez Microsoft Active Directory pour l'identité et l'authentification ; il s'agit de la méthode SSSD utilisée par SUSE. Par exemple, cette procédure utilise un hôte linux01et un domaine fictifs ad.example.com. Elle s'applique lorsque le client peut accéder aux services DNS et de temps d'Active Directory et que vous disposez d'informations d'identification d'inscription d'ordinateur valides.
Cette procédure suit le guide de sécurité et de renforcement de SLES 15 SP7 de SUSE. Les Service Packs antérieurs peuvent présenter des écrans YaST ou des informations de package différents ; utilisez donc le guide correspondant au Service Pack installé. Si votre besoin requiert spécifiquement la prise en charge de NTLM ou les approbations inter-forêts, SUSE recommande le module distinct « Appartenance au domaine Windows », basé sur Winbind, comme solution plus adaptée.
Avant de vous connecter : vérifiez le DNS, l’heure et l’identité de l’hôte
La découverte d'Active Directory repose sur les enregistrements DNS, et l'authentification Kerberos nécessite une horloge précise. Configurez le client SLES pour qu'il utilise un serveur DNS capable de résoudre le domaine Active Directory et ses contrôleurs de domaine ; généralement, cela signifie utiliser le serveur DNS d'Active Directory plutôt qu'un résolveur public. Synchronisez le client avec la source de temps approuvée pour votre domaine.
YaST Hostname/DNS affiche le champ Serveur de noms 1 avec une adresse d'exemple, à côté d'un terminal affichant la commande timedatectl. Il s'agit d'une illustration d'interface, et non d'un résultat de configuration capturé.
Dans YaST, ouvrez Network Settings, sélectionnez Hostname/DNS, et définissez Name Server 1l'adresse du serveur DNS Active Directory. L'adresse affichée dans l'illustration est un exemple. Vérifiez ensuite le nom d'hôte local et l'heure :
hostname
timedatectl status
Comparez le nom de l'ordinateur avec le nom enregistré dans Active Directory. En cas de différence, la boîte de dialogue d'intégration de SUSE propose un AD hostnamechamp de confirmation. Ne désactivez pas le pare-feu pour accélérer la découverte du domaine ; demandez à votre équipe réseau d'autoriser le trafic nécessaire entre le client et le contrôleur de domaine conformément aux règles de votre organisation. SUSE signale également que les noms se terminant par .example .localpeuvent entrer en conflit avec le DNS multicast ; vérifiez donc votre configuration DNS si votre domaine utilise cette extension.
Choisissez le module SSSD et ajoutez le domaine AD
Dans YaST, ouvrez User Logon Management. Ne choisissez pas Windows Domain Membershippour cette procédure : SUSE indique que ce module est basé sur Winbind, tandis que User Logon Management est l’option basée sur SSSD et est généralement préférée pour l’authentification AD.
La sélection du module YaST met en évidence la gestion des connexions utilisateur. Il s'agit d'une illustration d'interface, et non d'un résultat de configuration enregistré.
Ouvrez Change Settings, sélectionnez Add Domain, et saisissez le nom DNS du domaine, par exemple ad.example.com. Définissez le service d'identité et le service d'authentification sur Microsoft Active Directory, et assurez-vous Enable the domainque est sélectionné.
L'écran Gestion des connexions utilisateur affiche Modifier les paramètres et Ajouter un domaine. Il s'agit d'une illustration de l'interface, et non d'un résultat de configuration enregistré.La boîte de dialogue Ajouter un domaine affiche Microsoft Active Directory comme sélectionné pour l'identité et l'authentification, avec l'option Activer le domaine cochée. Il s'agit d'une illustration de l'interface, et non d'une configuration réelle.
Conservez les autres paramètres par défaut, sauf si votre environnement requiert un nom d'hôte Active Directory spécifique ou une liste fixe de contrôleurs de domaine. Si la découverte automatique DNS n'est pas appropriée, saisissez les noms d'hôte des contrôleurs de domaine fournis par votre équipe Active Directory. Cochez cette option OKpour que YaST puisse installer les logiciels manquants et vérifier si un contrôleur est accessible.
Inscrivez l'hôte et activez les connexions au domaine.
Lorsque YaST indique avoir détecté un serveur AD mais que l'ordinateur n'est pas encore inscrit, saisissez le compte et le mot de passe d'inscription autorisés. La boîte de dialogue documentée de SUSE utilise un compte d'administrateur AD ; suivez la procédure d'inscription approuvée par votre équipe d'annuaire et ne communiquez jamais le mot de passe dans un script ou un article. Si la boîte de dialogue ne parvient pas à détecter de serveur, vérifiez à nouveau le DNS et le nom d'hôte avant de réessayer.
La boîte de dialogue d'inscription indique qu'un serveur Active Directory a été détecté et affiche des champs Nom d'utilisateur et Mot de passe vides. Il s'agit d'une illustration d'interface, et non d'un résultat de configuration enregistré.
Après l'inscription, activez la fonctionnalité Allow Domain User Logon. L'activation Create Home Directoriesdépend de la stratégie de données utilisateur du serveur. Cette fonctionnalité crée des répertoires personnels locaux pour les utilisateurs Active Directory lors de leur première connexion ; elle est utile pour une machine qui doit conserver les données personnelles locales, mais elle ne crée ni ne gère le compte utilisateur dans Active Directory.
La section « Gérer l’ouverture de session des utilisateurs du domaine » affiche les options « Autoriser l’ouverture de session des utilisateurs du domaine » et « Créer des répertoires personnels ». Il s’agit d’une illustration de l’interface, et non d’un résultat de configuration.
Si Active Directory fournit déjà l'attribut de chaque utilisateur UnixHomeDirectory, vérifiez qu'il est renseigné et disponible conformément à la conception de votre annuaire. Si le client a besoin d'un chemin de secours, utilisez Service Options`<chemin> Name switch` Extended Optionspour le configurer fallback_homedir, par exemple `<chemin> /home/%u`. La documentation SUSE indique qu'un chemin de secours est utilisé lorsqu'aucun chemin Active Directory n'est fourni ; override_homedirdans ce cas, la valeur du client est prioritaire. Choisissez-en un uniquement après avoir consulté votre politique relative au répertoire personnel.
Les options étendues du commutateur Name indiquent que fallback_homedir est défini sur /home/%u. Il s'agit d'une illustration de l'interface, et non d'un résultat de configuration enregistré.
Enregistrez les paramètres et consultez le récapitulatif de configuration. Si le système utilise également Samba, ne sélectionnez l'option permettant de remplacer la configuration Samba que si cette intégration est prévue ; cette opération est indépendante de l'activation de l'ouverture de session utilisateur via SSSD.
Vérifiez SSSD, la recherche d'utilisateur et la connexion Kerberos.
Vérifiez que SSSD est actif, puis interrogez un compte de domaine réel en utilisant le format de nom approuvé pour votre domaine. Dans cet exemple, remplacez `<domain>` EXAMPLEet ` alice<compte>` par le nom de domaine court et `<compte>` par un compte de test existant :
Un terminal affiche les commandes permettant de vérifier le service SSSD, de rechercher un utilisateur de domaine d'exemple et d'inspecter le cache des tickets Kerberos. Il s'agit d'une illustration d'interface, et non d'un résultat de configuration enregistré.
systemctl status sssd
getent passwd 'EXAMPLE\alice'
La réception d'une entrée passwd confirme que NSS peut résoudre le compte ; elle ne prouve cependant pas à elle seule que l'utilisateur peut s'authentifier ou accéder aux applications. Testez une connexion interactive avec les identifiants de domaine, en utilisant le formulaire documenté DOMAIN_NAME\USER_NAMEsur la console ou le gestionnaire d'affichage. Après la connexion, exécutez la commande klistpour vérifier si la session possède un ticket Kerberos.
Si SSSD est en cours d'exécution mais que la résolution de compte utilisateur échoue, vérifiez le nom de domaine complet, le serveur DNS, le nom d'hôte et les paramètres d'identité et d'authentification dans YaST. Si la résolution réussit mais que la connexion échoue, vérifiez que le compte est activé, que son mot de passe est valide et que le client peut accéder au contrôleur de domaine. Terminez uniquement lorsqu'un utilisateur de test autorisé peut se connecter, que le comportement attendu du répertoire personnel est confirmé et que les services requis du serveur fonctionnent correctement.