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 -A host/client.ad.example.com@AD.EXAMPLE.COM client
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:

# yum install realmd sssd adcli samba-common-tools sssd-client sssd-libwbclient

Lancer la découverte de l’AD (il faut spécifier le domaine si NetworkManager n’est pas installé):

# realm discover nom.du.realm.ad

Joindre le serveur RHEL à l’AD :

# realm join nom.du.realm.ad -U username_d_un_administrateur_AD

Autoriser un groupe d’utilisateurs AD à se connecter :

# realm permit nom.du.realm.ad -g GROUPE_DES_ADMINS_UNIX

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 passwd utilisateur@nom.du.realm.ad

# 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) :

enumerate = True

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 :

services = nss, pam, autofs

Et rajouter [autofs] à la fin du fichier :

[autofs]

Dans /etc/auto.master, rajouter un point de montage autofs :

...
/cifs /etc/auto.cifs --timeout=60
...

Et créer le fichier /etc/auto.cifs :

* -fstype=cifs,sec=krb5,uid=$UID,gid=$GID,dir_mode=0700,cruid=$UID,username=&,domain=nom.du.realm.ad ://serveurdefichiers/nomdusharecifs

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.

Références: 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

0 réponses

Laisser un commentaire

Participez-vous à la discussion?
N'hésitez pas à contribuer!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.