Pour effectuer une Intégration RHEL 7 / Active Directory, il y a profusion d’articles sur Internet. Malheureusement, tous ces articles sont très techniques et font référence à des méthodes d’intégration qui sont, pour la plupart, obsolètes.
En outre, Microsoft a récemment rendu obsolète « Microsoft Windows Services for UNIX » qui était un pré-requis pour permettre l’authentification des utilisateurs AD sous Linux. Cet article fait donc le point sur comment, en 2017, intégrer Active Directory avec Red Hat Enterprise Linux 6 et 7.
La théorie
Il existe plusieurs possibilités pour interconnecter Red Hat Enterprise Linux avec Active Directory, classées en deux catégories : l’intégration directe et l’intégration indirecte.
L’intégration directe
L’intégration directe fait que le serveur RHEL est directement connecté à l’Active Directory, sans utilisation d’un serveur d’identification dédié à l’infrastructure Linux. Il existe plusieurs façons de mettre en place une intégration directe.
pam_ldap & pam_krb5
En configurant manuellement pam_ldap et pam_krb5, il est possible de connecter un RHEL à Active Directory, et c’est la façon qui était utilisée historiquement. Malheureusement, cette méthode est aujourd’hui obsolète car:
- trop complexe
- peu sécurisée
- elle ne fournit pas de cache et d’authentification offline
Winbind
Une autre façon de faire historique est d’utiliser la suite de logiciels Samba et en particulier Winbind. Cette méthode est aussi obsolète aujourd’hui .
SSSD
La méthode recommandée aujourd’hui par Red Hat pour effectuer une intégration directe entre RHEL et Active Directory est d’utiliser le daemon SSSD. C’est cette méthode dont nous allons parler dans la suite de cet article.
L’intégration indirecte
L’intégration indirecte consiste à mettre en place une infrastructure d’authentification dédiée à l’infrastructure Linux puis un mécanisme pour échanger des données entre cette infrastructure et Active Directory. Il existe plusieurs façons de mettre en place une intégration indirecte.
Trust
La mise en place d’un trust entre l’infrastructure d’authentification Linux et Active Directory consiste à faire apparaître l’infrastructure d’authentification Linux comme un nouvel arbre dans la forêt Active Directory. Les machines Linux doivent donc être placées dans une zone DNS dédiée.
Synchronisation
La synchronisation consiste à mettre en place des mécanismes permettant de dupliquer les informations Active Directory dans l’infrastructure d’authentification Linux. Un certain nombre d’inconvénients font que cette solution ne doit être considérée que dans des cas bien spécifiques :
- Nécessité de créer un utilisateur AD avec les droits de réplication.
- Nécessité de dupliquer les objets utilisateurs.
- Nécessité de synchroniser les mots de passe. Comme il est impossible de récupérer les mots de passe d’Active Directory, tous les utilisateurs doivent modifier une fois leur mot de passe pour qu’il soit stocké dans l’infrastructure d’authentification Linux.
- La réplication se fait à intervalles réguliers, donc il faut attendre que l’information soit dupliquée.
- Nécessité d’installer Password Synchronization Service sur chaque contrôleur de domaine AD.
- Cette méthode est déconseillée par Red Hat.
Trust ou SSSD ?
Les deux solutions possibles sont donc SSSD ou la mise en place d’un trust entre deux infrastructures d’authentification.
La mise en place d’un trust peut être très intéressante dans le cas où une infrastructure d’authentification serait déjà en place pour l’infrastructure Linux ou si une telle infrastructure était envisagée pour d’autres besoins que simplement l’interconnexion avec Active Directory.
Si le besoin est uniquement d’interconnecter les deux environnements, alors un certain nombre d’inconvénients font qu’il est préférable de choisir l’intégration directe :
- Nécessité d’avoir des serveurs RHEL7 ou RHEL6.4+
- Nécessité de déployer une infrastructure Red Hat IdM Server (avec tous les composants 389, Kerberos, Dogtag, DNS, SSSD, NTP, etc.), ce qui est un projet en soi, avec toute la complexité et les coûts associés.
- Nécessité de mettre en place une relation de trust entre l’Active Directory et IdM.
- Nécessité d’avoir 2008, 2008R2, 2012 ou 2012R2.
- Nécessité d’avoir un domaine DNS dédié aux serveurs Linux.
Installation et configuration
Pré-requis
Les étapes décrites dans cette documentation nécessitent d’avoir des outils relativement récents. Cette documentation ne fonctionne pas avec RHEL5.
Les avantages et inconvénients de la méthode d’intégration directe avec SSSD sont les suivants :
Avantages
- Caching d’authentification et donc baisse de la charge sur les contrôleurs de domaine AD
- Authentification offline
- Configuration très simple avec realmd
Inconvénients
- Nécessité d’entrer un mot de passe administrateur AD sur chaque poste Linux à intégrer dans le domaine
Firewall
Les pré-requis en termes de ports firewall à ouvrir entre les serveurs RHEL et les contrôleurs de domaine AD sont les suivants :
- 53/tcp
- 53/udp
- 389/tcp
- 389/udp
- 636/tcp
- 88/tcp
- 88/udp
- 464/tcp
- 464/udp
- 3268/tcp
- 3269/tcp
Autres
- Il faut s’assurer que le Linux soit correctement configuré en NTP.
- Il faut s’assurer que le Linux résolve correctement le DNS de l’AD et vice versa.
Microsoft Windows Services for UNIX ou ID mapping ?
Il existe deux façons de mettre en place une intégration directe avec SSSD. La première façon de faire est celle qui était historiquement supportée par Red Hat. Cette méthode nécessitait d’installer Microsoft Windows Services for UNIX pour rajouter au schéma LDAP de l’AD les attributs POSIX nécessaires à l’authentification Linux. Microsoft Windows SFU est maintenant déprécié (https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/) et il faut donc utiliser une nouvelle méthode qui consiste à faire du mapping d’ID. Le mapping d’ID va permettre de mapper des SID Windows vers des UID Linux de façon cohérente et identique sur chaque serveur.
Nécessité de passer sur chaque serveur Linux pour joindre le serveur à l’AD
Afin de résoudre l’inconvénient de devoir passer sur chaque serveur Linux pour le joindre à l’AD, il est possible de pré-créer les objets Computer dans l’AD, d’exporter les keytabs vers les serveurs Linux et de joindre les serveurs au domaine sans donner le mot de passe de l’administrateur AD :
Sur un DC, ouvrir « Active Directory Users and Computers » et créer un nouvel objet Computer dans l’OU Computer. Le nom doit correspondre au nom court du Linux. Attention, 15 caractères maximum.
Ouvrir un cmd et lancer:
setspn -L client
ktpass /princ host/client.ad.example.com@AD.EXAMPLE.COM /out client-host.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser ADclient$ +setupn +rndPass +setpass +answer
(remplacer client par le nom court du Linux et ad.example.com par le DNS de l’AD).
Copier client-host.keytab dans le /etc/krb5.keytab du Linux
Plus d’informations ici : https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
Installation
Les étapes de l’installation sont celles décrites dans le document https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Windows_Integration_Guide/Red_Hat_Enterprise_Linux-7-Windows_Integration_Guide-en-US.pdf chapitre “Chapter 3. Using realmd to Connect to an Active Directory Domain”.
Installer le paquet realmd:
Lancer la découverte de l’AD (il faut spécifier le domaine si NetworkManager n’est pas installé):
Joindre le serveur RHEL à l’AD :
Autoriser un groupe d’utilisateurs AD à se connecter :
Ensuite, il s’agit d’utiliser la configuration sudo pour affiner les droits des membres du groupe à passer root. Il est aussi possible de mettre en place du whitelisting dans la configuration SSH pour n’autoriser que certains membres du groupe à se connecter en SSH sur tel ou tel serveur (cette whitelist pourrait éventuellement être gérée de façon centralisée par un outil de gestion des configurations tel que Puppet).
Tests
Pour lister les utilisateurs et les groupes AD, il faut utiliser les commandes :
# getent group
Pour autoriser l’énumération des groupes et utilisateurs, il faut rajouter la ligne suivante à la fin de /etc/sssd.conf (ceci est déconseillé pour des raisons de performance) :
Connexion à des shares Windows
Il est impossible pour un utilisateur de faire un mount d’un share CIFS avec son ticket Kerberos. La solution est d’utiliser automount.
Dans /etc/sssd/sssd.conf, rajouter autofs à la ligne services :
Et rajouter [autofs] à la fin du fichier :
Dans /etc/auto.master, rajouter un point de montage autofs :
/cifs /etc/auto.cifs --timeout=60
...
Et créer le fichier /etc/auto.cifs :
Lorsque l’utilisateur ira dans /cifs, il aura accès, avec authentification automatique, aux fichiers du share CIFS nomdusharecifs. Afin de faciliter l’accès aux shares aux utilisateurs, il est possible de créer des liens symboliques depuis leurs répertoires personnels vers les shares ainsi créés.
Laisser un commentaire
Participez-vous à la discussion?N'hésitez pas à contribuer!