Depuis la version 3.3 de FreeIPA, il est possible d’établir des relations d’approbation (Trust Relationships) entre un domaine IPA et un domaine Active Directory, ces fonctionnalités ont été renforcées dans les versions suivantes :
- 4.1 : ID Views
- 4.2 : One-Way Trust
- 4.4 : Certificats pour utilisateurs AD, Support des UPN pour les Trusts
- 4.5 : Support des noms courts pour les utilisateurs AD, mise à jour semi-automatique des enregistrements DNS externes
- 4.6.6 : Création One-Way Trust avec secret
- 4.8 : Trusts avec Contrôleurs des Domaines Samba 4.7+
Côté AD, pour un fonctionnement optimal, nous aurons besoin de Windows Server 2012 R2 a minima.
Trust / Relation D’approbation
Trust en anglais, Relation d’approbation en français, est un lien de confiance entre 2 forêts, voir 2 domaines.
Habituellement réalisés entre contrôleurs de domaines active directory, il est également possible d’intégrer un environnement Linux avec un environnement Windows via un Trust entre une forêt AD et son équivalent FreeIPA.
Il s’agit de la méthode actuelle et recommandée pour intégrer un environnement Linux/FreeIPA et Windows/AD. L’ancienne méthode “winsync” qui consistait à synchroniser les comptes est dépréciée et déconseillée.
Types d’intégration
Il existe plusieurs types d’intégration :
Relation D’approbation unidirectionnelle (One-way Trust)
L’intégration la plus classique, il permet d’utiliser des comptes utilisateurs Windows sur les machines Linux.
One way trustLe domaine FreeIPA fait confiance à la forêt AD, les utilisateurs AD de la forêt peuvent accéder aux ressources du domaine FreeIPA, l’inverse n’est pas vrai.
Relation D’approbation unidirectionnelle transitive (Transitive One-way Trust)
Si plus de 2 forêts sont impliquées dans l’infrastructure, les trusts peuvent être (ou non) transitifs, dans notre exemple, le domaine FreeIPA fait confiance au domaine AD 1, qui fait lui même confiance au domaine AD 2, dans le cadre d’un domaine transitif, le domaine FreeIPA fait confiance au domaine AD 2.
Relation D’approbation bidirectionelle (Two-Way Trust)
La relation d’approbation est établie dans les deux sens, les utilisateurs des deux domaines peuvent accéder aux ressources des deux domaines.
Relation D’approbation Externe (External Trusts)
Comme nous l’avons vu au dessus, un trust se crée entre forêts, dans le cas où votre forêt contient plusieurs domaines, tout les domaines de la forêt auront accès aux ressources du domaine IPA, dans ce cas nous pouvons souhaiter établir le trust uniquement entre un domaine particulier de la forêt et notre domaine IPA.
Utilisateurs Active Directory et attributs POSIX
Une des principales difficultés de l’intégration Windows / Linux réside dans l’utilisation de méthodes différentes pour identifier des objets (utilisateurs, groupes…) sur un système, SID (Security Identifier) côté Windows, et UID/GID côté Linux.
De plus, dans FreeIPA, l’appartenance à des groupes est exprimée via un DN, un objet LDAP. Les utilisateurs AD n’étant pas synchronisés dans l’arborescence LDAP dans le cadre d’un trust, nous avons besoin d’un autre méthode pour ajouter des utilisateurs AD à des groupes FreeIPA, pour la gestion des règles HBAC ou sudo par exemple.
Rôle AD “Server for NIS”
Il s’agit de la méthode historique, il permet d’ajouter des attributs unix à des utilisateurs AD (UID, Shell…), ces données sont lisibles et interprétables par FreeIPA pour autoriser l’accès d’un utilisateur AD à un système Linux.
Cependant, cette méthode est de plus en plus dépréciée, à partir de Windows Server 2016, ces options ne sont plus accessibles en mode graphique, les fonctionnalités et attributs sont cependant toujours présents et fonctionnels, modifiables directement via des requêtes LDAP par exemple.
Cette méthode est déconseillée.
Trust + Groupes FreeIPA “Externes” et ID Views
Il s’agit de la méthode recommandée actuellement et qui sera utilisée dans cet article, dans ce mode c’est FreeIPA qui ajoutera un UID/Shell/etc.. à l’utilisateur AD lors de sa connexion.
Groupe Externes
Les groupes externes, “Non-Posix External Groups” sont des objets particuliers dans FreeIPA, ils permettent l’intégration d’utilisateurs AD (externes) dans des groupes internes à FreeIPA.
Une fois le groupe externe populé avec les utilisateurs AD, il sera intégré dans une groupe “POSIX” afin d’y être assigné un GID, que le groupe puisse être ensuite utilisé par le reste du système (HBAC, sudo…)
ID Views
Cette fonctionnalité permet de surcharger les identifiants POSIX d’un utilisateur AD (UID, Shell…) Cela permet également d’ajouter un certificat ou une clé publique SSH à un utilisateur AD.
ID Range
Lors de la création d’un trust, FreeIPA va automatiquement créer un “ID Range” supplémentaires qui assignera des UID automatiquement aux utilisateurs AD, leur permettant de se connecter sans plus de réglages.
Par défaut lors de la création d’un trust, sera choisi une fourchette de 200000 IDs parmi 10000 choix de fourchettes possibles.
À noter que si il existe plusieurs replicas FreeIPA, ce range sera découpé en fonction du nombre de réplicas. par exemple, dans un système à 2 replicas, chaque replica aura un range de 100000 IDs (200000/2).
Architecture du Trust
Communication AD / FreeIPA
DNS
La configuration du DNS sera un pré-requis important pour le succès d’un trust, si le DNS intégré de FreeIPA est utilisé, les enregistrements seront crées automatiquement, si l’on a préféré utiliser un autre DNS (celui de notre AD par exemple), il faudra bien déclarer les DNS Manuellement.
Chaque environnement doit être sur une zone DNS séparée. Par exemple :
- ad.acme.com pour AD et ipa.acme.com pour IPA
- acme.com pour AD et ipa.acme.com pour IPA
- ad.acme.com pour AD et acme.com pour IPA
Enregistrements SRV
_kerberos-master._tcp.linux.acme.com.
_kerberos._tcp.linux.acme.com.
_kpasswd._tcp.linux.acme.com.
_kerberos-master._udp.linux.acme.com.
_kerberos._udp.linux.acme.com.
_kpasswd._udp.linux.acme.com.
_ldap._tcp.linux.acme.com.
_kerberos._tcp.dc._msdcs.linux.acme.com.
_kerberos._udp.dc._msdcs.linux.acme.com.
_ldap._tcp.dc._msdcs.linux.acme.com.
Ces enregistrements doivent retourner vos serveurs IPA avec le port et le poids associés au service.
Enregistrement TXT
_kerberos.linux.acme.com.
Cet enregistrement doit retourner le nom du domaine Kerberos.
Tester vos enregistrements :
dig +short _kerberos-master._tcp.linux.acme.com. SRV
dig +short _kerberos._tcp.linux.acme.com. SRV
dig +short _kpasswd._tcp.linux.acme.com. SRV
dig +short _kerberos-master._udp.linux.acme.com. SRV
dig +short _kerberos._udp.linux.acme.com. SRV
dig +short _kpasswd._udp.linux.acme.com. SRV
dig +short _ldap._tcp.linux.acme.com. SRV
dig +short _kerberos.linux.acme.com. TXT
dig +short _kerberos._tcp.dc._msdcs.linux.acme.com. SRV
dig +short _kerberos._udp.dc._msdcs.linux.acme.com. SRV
dig +short _ldap._tcp.dc._msdcs.linux.acme.com. SRV
Les différents tests dig doivent retourner vos serveurs FreeIPA ainsi que votre domaine Kerberos.
Firewall
Il y aura des ports supplémentaires à vérifier/ouvrir sur votre firewall.
Source Destination Protocole Port Service
IPA AD tcp 53 DNS
IPA AD tcp 88 Kerberos
IPA AD tcp 135 epmap
IPA AD tcp 138 netbios
IPA AD tcp 139 netbios
IPA AD tcp 445 Microsoft-DS
IPA AD tcp 389 Ldap TLS
IPA AD tcp 636 Ldaps
IPA AD tcp 1024-1500 epmap
IPA AD tcp 3268 Microsoft-Global Catalog
IPA AD udp 53 DNS
IPA AD udp 88 Kerberos
IPA AD udp 123 ntp
IPA AD udp 138 netbios
IPA AD udp 139 netbios
IPA AD udp 389 ldap
AD IPA tcp 53 DNS
AD IPA tcp 88 Kerberos
AD IPA tcp 135 epmap
AD IPA tcp 138 netbios
AD IPA tcp 139 netbios
AD IPA tcp 445 Microsoft-DS
AD IPA tcp 389 Ldap TLS
AD IPA tcp 636 Ldaps
AD IPA tcp 1024-1500 epmap
AD IPA udp 53 DNS
AD IPA udp 88 Kerberos
AD IPA udp 138 netbios
AD IPA udp 139 netbios
AD IPA udp 389 ldap
Authentification
La mise en place d’un trust peut être réalisée de 2 façons :
- Via un compte administrateur
- Via un secret partagé
Dans le premier cas, un administrateur autorisé par l’AD à créer des trusts entre son login/mdp lors de la création du trust.
Dans le second cas, l’administrateur AD va initier le trust avec un secret, qu’il partagera avec l’administrateur IPA pour finir l’initialisation du Trust.
En fonction du type de trust choisi, l’initialisation du trust via clé partagée peut ne pas etre possible.
Trust Controllers & Trust Agents
Il s’agit de rôles que l’on peux ajouter (ou non) a des réplica, pour qu’ils puissent également interroger l’AD.
- Trust Agent : Serveur FreeIPA qui peux interroger le domaine AD
- Trust Controller : Serveur FreeIPA qui peux interroger le domaine AD et gérer la configuration du trust.
Il est conseillé d’avoir a minima 2 trusts controllers par site.
Schéma de communication détaillé
Ce schéma est présent à titre indicatif, il se concentre sur les spécificités d’une connexion d’un utilisateur d’un trust et ne fait volontairement pas mention des autres traitements réalisés lors d’une connexion, comme le traitement des règles HBAC ou sudo. Le client est configuré pour utiliser le proxy KDC de FreeIPA (kdcproxy), dans le cas contraire, le client aurait obtenu un ticket kerberos directement depuis l’AD.
- L’utilisateur AD se connecte sur une machine linux connectée à FreeIPA.
- SSHD transmet la demande de connexion à PAM
- Dans notre cas PAM va utiliser pam_sss.so, redirigeant la demande de connexion à SSSD
- Le module sssd_pam transmet la demande à sssd_be, le module qui permet d’interroger les backends d’authentification configurés
- sssd_be interroge le serveur IPA via un plugin spécifique
- L’opération est reçue par le service LDAP, qui interroge le module sssd_nss
- Le demande est transmise à sssd_be
- Le processus sssd_be demande a l’AD les données de l’utilisateur
- Le processus sssd_be les met en cache, une fois l’objet mis en cache, le flux s’inverse, le module sssd_be informe le module sssd_nss que le cache est à jour, le processus sssd_nss informe enssuite le client via retour de l’opération LDAP précédement réalisée.
- La requete revient au client, il vérifie si les données sont déjà présentes dans le cache
- sssd_be démarre le processsus krb5_child pour obtenir un ticket kerberos
- krb5_child interroge le proxy KDC pour un ticket kerberos pour l’utilisateur
- Le proxy KDC transmet la demande au KDC de l’AD
- Le TGT utilisateur revient de l’AD, il y est attaché un “blob” appelé MSPAC, ce dernier contient des informations supplémentaires de l’utilisateur (groupes, acl…)
- Le processus sssd_pac traiteIDM les appartenances aux groupes AD pendant la connection, ce processus nécessite de résoudre les SID en noms POSIX et GID, pour chaque SID rencontré, une demande est réalisée auprès de sssd_be.
- Tous les groupes du MSPAC on été traités, si l’utilisateur est autorisé, le service sssd_nss sera informé et l’utilisateur connecté.
C’est tout pour notre Partie 5, en partie 6 nous mettrons ces informations en pratique, nous connecterons un AD à notre environnement IPA et nous nous connecterons sur une machine linux avec un utilisateur AD.
Notre série sur FreeIPA
Si vous ne les avez pas encore lu, retrouvez notre série d’articles sur FreeIPA :
- FreeIPA Partie 1 : Installation du serveur et de son réplica
- FreeIPA Partie 2 : Clients, HBAC, Sudo, Mots de passe
- FreeIPA Partie 3 : Haute-disponibilité, Automount
- FreeIPA Partie 4 : Seconds facteurs d’authentification
- FreeIPA Partie 5 : Trusts Active Directory
- FreeIPA Partie 6 : Trusts Active Directory, mise en pratique
