Logo freeIPA

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. Interface administrateur freeipainterface administrateur freeipainterface administrateur freeipa

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)

Interface administrateur freeipainterface administrateur freeipainterface administrateur freeipa

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)

Interface administrateur freeipainterface administrateur freeipainterface administrateur freeipa

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)

Interface administrateur freeipainterface administrateur freeipainterface administrateur freeipa

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.

Interface administrateur freeipainterface administrateur freeipainterface administrateur 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.

Interface administrateur freeipainterface administrateur freeipainterface administrateur freeipa

  1. L’utilisateur AD se connecte sur une machine linux connectée à FreeIPA.
  2. SSHD transmet la demande de connexion à PAM
  3. Dans notre cas PAM va utiliser pam_sss.so, redirigeant la demande de connexion à SSSD
  4. Le module sssd_pam transmet la demande à sssd_be, le module qui permet d’interroger les backends d’authentification configurés
  5. sssd_be interroge le serveur IPA via un plugin spécifique
  6. L’opération est reçue par le service LDAP, qui interroge le module sssd_nss
  7. Le demande est transmise à sssd_be
  8. Le processus sssd_be demande a l’AD les données de l’utilisateur
  9. 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.
  10. La requete revient au client, il vérifie si les données sont déjà présentes dans le cache
  11. sssd_be démarre le processsus krb5_child pour obtenir un ticket kerberos
  12. krb5_child interroge le proxy KDC pour un ticket kerberos pour l’utilisateur
  13. Le proxy KDC transmet la demande au KDC de l’AD
  14. 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…)
  15. 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.
  16. 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 :

  1. FreeIPA Partie 1 : Installation du serveur et de son réplica
  2. FreeIPA Partie 2 : Clients, HBAC, Sudo, Mots de passe
  3. FreeIPA Partie 3 : Haute-disponibilité, Automount
  4. FreeIPA Partie 4 : Seconds facteurs d’authentification
  5. FreeIPA Partie 5 : Trusts Active Directory
  6. FreeIPA Partie 6 : Trusts Active Directory, mise en pratique