(modifié le 2 mai 2024 à 2:05)

Rejoindre un domaine Microsoft Active Directory à partir d'une machine Linux n'est pas toujours facile. Tout d'abord parce la méthode diffère en fonction des distributions, mais également parce qu'il existe plusieurs façons pour joindre un domaine AD.

J'ai découvert l'existance d'un générateur de script bash pour rejoindre un domaine AD avec Winbind ou SSSD.

SSSD vs Winbind ?

Pourquoi utiliser SSSD plutôt que Winbind ? Voilà une très bonne question.

Pour y répondre je vais prendre (volontairement) de gros raccourcis :

  • Si vous êtes en mono-domaine et mono-forêt alors SSSD est recommandé
  • Si vous disposez de relations d'approbations entre forêts (cross forest AD trusts) alors SSSD nécessite de créer un compte ordinateur dans chaque domaine. Alors que winbind non 🙂

En bref : préférez SSSD qui est plus récent que winbind, il est aussi plus sécurisé et s'appuie sur Kerberos. Notez aussi que SSSD ne sait pas dialoguer avec NTLM.

Le générateur de script (de RedHat)

Le script est compatible avec RHEL 7, RHEL 8 et RHEL 9 (et toutes les distributions dérivées de RHEL dans les mêmes versions: Rocky Linux, AlmaLinux, etc).

➡️Accéder au générateur de script (AD Integration Helper)

Malheureusement ce générateur est réservé aux personnes ayant une souscription RedHat. Même si vous profitez des 16 licences développeur gratuites cela ne fonctionnera pas. Mais tout n'est pas perdu. Déjà parce que la documentation officielle RHEL est accessible à tous :

Ce script n'a rien de magique mais il permet aux débutants de ne pas se prendre la tête, grâce aux valeurs saisies en formulaire web et injectés en variables bash. Il fait aussi un backup de vos configurations actuelles par précaution.

Rejoindre un domaine AD à la main avec RHEL 8

Il est tout à fait possible de faire la même chose sans script à la mano.

Dans mon exemple le nom FQDN de mon domaine AD est "BM.LAB", son nom court est "BM" et mon compte permettant de joindre le domaine est "moncompteadmin".

Paquets Winbind :

yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients samba-winbind samba-common-tools samba-winbind-krb5-locator samba
realm join --user=moncompteadmin --membership-software=samba --client-software=winbind --server-software=active-directory BM.LAB
systemctl enable --now smb

Paquets SSSD :

yum install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
realm join --user=moncompteadmin --client-software=sssd --server-software=active-directory BM.LAB

Paquets SSSD avec Samba :

yum install realmd oddjob oddjob-mkhomedir sssd adcli samba samba-winbind krb5-workstation
realm discover BM.LAB
realm join -U moncompteadmin --client-software=sssd --membership-software=samba BM.LAB
cat > "/etc/samba/smb.conf" << EOF
[global]
realm = BM.LAB
workgroup = BM
security = ads
kerberos method = secrets and keytab 
template homedir = /home/%U
idmap config * : backend = tdb
idmap config * : range = 10000-199999
idmap config BM : backend = sss
idmap config BM : range = 200000-2147483647
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
machine password timeout = 0 
EOF
systemctl enable --now smb winbind

Tutoriels RHEL

Si ce petit guide rapide ne vous suffit pas, je vous propose également 2 sites qui proposent un tutoriel pour SSSD et Winbind pour RHEL 8 :

Joindre un AD avec Winbind (net ads) :

Joindre un AD avec SSSD (realm) :

⚠️ Par défaut n'importe quel utilisateur de l'AD peut se connecter, alors n'oubliez pas d'aller gérer l'authentification SSH dans /etc/pam.d/sshd (comprendre la différence entre requisite, sufficient, required et optional).

Tutoriels Debian / Ubuntu

Si vous êtes sous Debian il faut adapter les noms des paquets :

Conclusion

Si vous êtes arrivés à la fin de cet article et que vous vous demandez pourquoi faire rejoindre une machine Linux dans un domaine AD Microsoft ? c'est vrai que j'aurais du commencer par ça.

La réponse : permettre à des utilisateurs de votre domaine AD de se connecter à des machines Linux via SSH, sans devoir le communiquer le mot de passe root ni leur créer de compte locaux. Si vous êtes tout seul à administrer vos serveurs vous n'aurez probablement pas d'intérêt à réaliser cette jointure. En revanche si vous travaillez en équipe alors dès qu'un petit nouveau arrive il vous suffit de l'ajouter dans les bon groupes pour avoir accès aux machines.

D'un point de vue sécurité : si quelqu'un quitte l'entreprise (ou votre équipe) vous n'aurez pas besoin de changer tous les mots de passe root car il ne les connait pas. En effet il a toujours utilisé son compte nominatif pour se connecter 🙂

J'espère que cet article vous aura éclairé un peu, c'est un vaste sujet et il est difficile d'en parler sans rentrer dans les détails déjà présents dans la documentation RHEL.

En cas d'erreur de connexion jetez un oeil aus logs dans  /var/log/secure sur RHEL ou /var/log/messages sur Debian. Je vous partagerai encore quelques commandes utiles dans un futur article (si j'y pense ^^).

 

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter