Un poste Ubuntu peut rejoindre un domaine Windows et s’appuyer sur Active Directory pour authentifier ses utilisateurs, sans transformer Linux en imitateur de Windows. La clé d’une intégration Linux fiable tient à quelques fondations bien réglées : DNS, synchronisation horaire, realmd et SSSD. Voici une méthode progressive pour préparer la machine, effectuer la jonction au domaine et contrôler les accès.
L’article en bref
Intégrer Ubuntu à Active Directory centralise l’authentification et simplifie la gestion des accès dans un réseau mixte. La configuration repose d’abord sur un DNS capable de localiser les contrôleurs de domaine.
- Préparer le terrain : Vérifier le DNS, l’heure système et le nom d’hôte.
- Installer les outils : Utiliser realmd, SSSD et les composants Kerberos nécessaires.
- Rejoindre le domaine : Découvrir Active Directory, puis effectuer la jonction.
- Maîtriser les accès : Configurer les connexions, dossiers personnels et droits sudo.
Une configuration méthodique rend l’authentification Linux plus simple à administrer et à diagnostiquer.
Préparer Ubuntu avant la jonction à Active Directory
Dans un réseau mixte, l’intégration Linux ne commence pas par la commande de jonction, mais par la résolution des noms. Pour l’exemple, le domaine est office.local et ses serveurs DNS sont 192.168.0.1 et 192.168.0.2. Adaptez ces valeurs à votre infrastructure : Ubuntu doit interroger les DNS du domaine, capables de trouver les contrôleurs et leurs enregistrements de service.
Choisissez aussi un nom d’hôte unique, par exemple ubuntu-poste-15, et vérifiez que l’horloge de la machine reste synchronisée avec celle du domaine. Un décalage important peut faire échouer l’authentification Kerberos : ce mécanisme de tickets est précis, et ne pardonne pas les montres qui prennent leur propre scénario.
Sur une installation Ubuntu 20.04, le support standard est terminé depuis 2025 ; en 2026, il faut disposer d’Ubuntu Pro avec la maintenance de sécurité étendue ou privilégier une version encore prise en charge. Mettez le système à jour avec sudo apt update puis sudo apt upgrade.
| Élément | Valeur d’exemple | Vérification utile |
|---|---|---|
| Domaine AD | office.local | Nom identique à celui configuré dans Active Directory |
| DNS primaire et secondaire | 192.168.0.1 et 192.168.0.2 | Résolution des noms et des contrôleurs de domaine |
| Nom d’hôte Ubuntu | ubuntu-poste-15 | Nom unique, différent de localhost |
| Horloge système | Synchronisée avec l’infrastructure | Écart suffisamment faible pour Kerberos |
Configurer le DNS et installer realmd avec SSSD
Si Ubuntu reçoit sa configuration réseau par DHCP, vérifiez que le serveur DHCP lui transmet bien les DNS du domaine. En configuration statique, ouvrez le fichier Netplan avec sudo nano /etc/netplan/*.yaml et indiquez les serveurs DNS ainsi que le suffixe de recherche office.local. Le nom exact de l’interface et la passerelle dépendent de la machine ; une erreur de nom d’interface suffit à rendre la configuration inopérante.
Après modification, appliquez Netplan avec sudo netplan apply, puis vérifiez que les noms du domaine et des contrôleurs sont résolus. Évitez de modifier directement /etc/resolv.conf lorsqu’il est généré automatiquement : la configuration persistante se règle généralement dans Netplan ou via le gestionnaire réseau utilisé par le système.
Installez ensuite les outils nécessaires à l’authentification Kerberos et à la gestion des identités par SSSD : sudo apt install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin packagekit. Samba fournit des composants utiles dans cet environnement, mais cette méthode s’appuie sur realmd et SSSD plutôt que sur une configuration Winbind complète.
Pour une vérification rapide, contrôlez la résolution DNS du contrôleur et l’accès réseau avant de poursuivre. Si la machine ne trouve pas le service, mieux vaut corriger DNS maintenant que chercher plus tard un mystérieux problème de mot de passe.
Découvrir Active Directory et effectuer la jonction au domaine
Lancez realm discover office.local. Une réponse présentant le domaine et son type Kerberos indique que la découverte fonctionne. Si aucune information ne remonte, vérifiez d’abord les DNS, le nom de domaine, l’accès au contrôleur et la synchronisation horaire : la commande sert aussi de test de préparation.
Lorsque le domaine est détecté, effectuez la jonction avec sudo realm join -U admin office.local, en remplaçant admin par un compte autorisé à ajouter des ordinateurs au domaine. Saisissez son mot de passe à l’invite, puis vérifiez le résultat avec realm list. Cette opération crée l’association entre Ubuntu et Active Directory ; ce n’est pas encore une autorisation automatique pour tous les utilisateurs.
Testez ensuite la consultation d’un compte avec id [email protected], en remplaçant utilisateur par un compte existant. Si les informations d’identité et les groupes apparaissent, SSSD parvient à interroger le domaine. C’est le moment où la jonction cesse d’être une simple ligne de commande et devient une connexion vérifiable.
Configurer SSSD, les dossiers personnels et les droits d’accès
Par défaut, les connexions peuvent demander le nom complet du compte, sous la forme [email protected]. Pour utiliser simplement le nom d’utilisateur, ouvrez /etc/sssd/sssd.conf et, dans la section du domaine, réglez use_fully_qualified_names = False. Le fichier contient des paramètres sensibles : conservez ses permissions restrictives, puis redémarrez SSSD avec sudo systemctl restart sssd.
Vérifiez le changement avec id utilisateur. Si les informations ne se mettent pas à jour, examinez l’état du service avec systemctl status sssd et ses journaux. Dans un domaine où plusieurs utilisateurs portent le même nom, garder les noms complets évite les ambiguïtés ; ce choix dépend donc aussi de l’organisation des comptes.
Pour créer automatiquement un dossier personnel lors de la première connexion, activez le module PAM avec sudo pam-auth-update, puis sélectionnez la création automatique des répertoires personnels si elle est proposée. Vérifiez ensuite l’ouverture d’une session avec su – utilisateur ou une connexion graphique. La création du dossier à la première session évite de gérer ces répertoires un par un.
Enfin, limitez l’accès aux comptes réellement nécessaires. Vous pouvez refuser les connexions par défaut, puis autoriser des utilisateurs précis avec sudo realm deny –all et sudo realm permit [email protected]. Pour autoriser un groupe, utilisez sudo realm permit -g ‘Domain Admins’ après avoir confirmé son nom exact dans votre environnement.
Les privilèges sudo doivent rester distincts de la simple autorisation de connexion. Utilisez sudo visudo -f /etc/sudoers.d/admins pour créer une règle validée, puis ajoutez uniquement les utilisateurs ou groupes nécessaires. Une attribution directe à un utilisateur doit respecter la forme utilisateur ALL=(ALL:ALL) ALL ; pour un groupe AD, vérifiez d’abord son nom tel qu’il est exposé par le système.
| Besoin | Action | Contrôle |
|---|---|---|
| Connexion par nom court | Régler use_fully_qualified_names dans SSSD | Tester avec id utilisateur |
| Dossier personnel automatique | Activer la création de répertoire via PAM | Ouvrir une première session utilisateur |
| Limiter les connexions | Combiner realm deny et realm permit | Tester un compte autorisé et un compte refusé |
| Accorder sudo | Créer une règle dédiée avec visudo | Vérifier le groupe et les droits accordés |
Questions courantes sur Ubuntu et Active Directory
Avant de déployer la configuration sur plusieurs postes, quelques contrôles permettent d’éviter les erreurs les plus fréquentes. Le DNS et les autorisations restent les deux points à examiner en premier lorsqu’une connexion échoue.
Ubuntu a-t-il besoin des DNS du domaine pour découvrir Active Directory ?
Oui. Le poste doit pouvoir interroger les DNS qui connaissent les enregistrements Active Directory et localisent les contrôleurs de domaine. Un DNS public seul ne suffit généralement pas à cette découverte.
Que vérifier si realm discover ne trouve pas le domaine ?
Contrôlez le nom du domaine, les DNS configurés dans Ubuntu, la résolution des noms des contrôleurs, l’accès réseau et la synchronisation de l’heure. Ces éléments sont nécessaires avant la jonction.
Peut-on se connecter sans saisir le suffixe du domaine ?
Oui. Le paramètre use_fully_qualified_names = False dans la section du domaine de sssd.conf autorise généralement l’usage du nom court. Dans un environnement comportant des noms dupliqués, le nom complet reste plus sûr.
Comment limiter les comptes autorisés à ouvrir une session ?
Utilisez realm deny –all pour bloquer les accès par défaut, puis realm permit pour autoriser des utilisateurs ou groupes précis. Vérifiez le nom exact des groupes reconnus par la machine.
Les utilisateurs AD peuvent-ils recevoir des privilèges sudo ?
Oui. Ajoutez une règle ciblée dans un fichier de /etc/sudoers.d/ en utilisant visudo. Accordez uniquement les privilèges requis et vérifiez le nom de compte ou de groupe tel qu’il apparaît sur Ubuntu.
