Comment configurer et sécuriser les relations d'approbation Active Directory

Qu'est-ce qu'une relation d'approbation Active Directory

Une relation d'approbation Active Directory (trust) permet à un contrôleur de domaine d'un domaine de se porter garant de l'identité d'un compte authentifié dans un domaine ou une forêt différente. En interne, chaque relation d'approbation est stockée sous la forme d'un objet TDO (Trusted Domain Object) qui enregistre le nom du domaine approuvé, la direction, la transitivité, et un secret partagé — le mot de passe de la relation d'approbation — utilisé pour protéger le trafic d'authentification qui la traverse. Les relations d'approbation Active Directory sont ce qui rend une forêt multi-domaines utilisable : sans elles, chaque domaine serait un îlot d'authentification isolé, sans aucun moyen de référencer des utilisateurs ou des groupes provenant d'ailleurs.

Une relation d'approbation, à elle seule, n'accorde aucun accès. Elle ne fait qu'étendre le chemin d'authentification — ce que le compte demandeur peut réellement atteindre de l'autre côté reste gouverné par les ACL, l'appartenance aux groupes et les paramètres de délégation. Cela dit, une relation d'approbation mal configurée élargit le rayon d'impact d'une compromission de part et d'autre, c'est pourquoi la configuration des relations d'approbation mérite la même rigueur que tout autre changement Tier 0.

Types de relations d'approbation et transitivité

Toutes les relations d'approbation ne se comportent pas de la même façon. Deux propriétés déterminent la portée réelle d'une relation d'approbation : la direction (quel côté peut authentifier ses utilisateurs vers l'autre) et la transitivité (si la relation s'étend implicitement aux domaines que le côté approuvé approuve lui-même).

Deux conséquences comptent pour le durcissement :

• Les chaînes de transitivité. Une relation d'approbation de forêt transitive ne s'arrête pas à la racine de la forêt — elle s'étend à chaque domaine à l'intérieur de cette forêt. Approuver une forêt revient à approuver chaque administrateur de domaine qu'elle contient, pas seulement l'équipe qui a demandé l'intégration.
• La direction limite l'exposition. Une relation d'approbation unidirectionnelle où le domaine A approuve le domaine B permet aux utilisateurs de B de s'authentifier dans A, mais pas l'inverse. Là où le besoin métier est unidirectionnel, configurer une relation bidirectionnelle « par précaution » ne fait qu'ajouter un chemin d'authentification que personne n'a demandé. TRUST_BIDIRECTIONAL dans le catalogue EtcSec signale toute relation d'approbation bidirectionnelle externe, de forêt ou inter-arborescence (les relations parent-enfant sont exclues, puisqu'elles sont bidirectionnelles par conception) — un signal de configuration à revoir, pas une certitude que le trafic ne circule que dans un sens en pratique.

Comment configurer une relation d'approbation sécurisée, étape par étape

Les étapes ci-dessous se concentrent sur les relations externes et de forêt — les cas qui nécessitent un durcissement délibéré. Les relations parent-enfant et de racine d'arborescence sont créées automatiquement par le processus de promotion de domaine et de forêt et héritent des paramètres par défaut de la forêt ; le filtrage SID ne s'applique pas à elles par conception, car l'historique SID entre domaines d'une même forêt est attendu.

Étape 1 — Planifier la relation d'approbation avant de la créer

Notez, avant d'ouvrir la moindre console : quel côté initie l'authentification, si elle doit être unidirectionnelle ou bidirectionnelle, quelles ressources le côté approuvé doit réellement atteindre, qui possède la relation, et une date de revue. Une relation d'approbation sans propriétaire et sans date de revue est celle qui sera encore ouverte cinq ans après la fin du projet qui l'avait demandée.

Étape 2 — Créer la relation d'approbation

Créez la relation d'approbation depuis la console Domaines et approbations Active Directory (assistant Nouvelle approbation), ou de façon non interactive avec netdom :

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Retirez /twoway pour une relation unidirectionnelle — faites correspondre la commande à ce que l'Étape 1 exige réellement, pas à ce qui se clique le plus vite.

Étape 3 — Restreindre le chiffrement de la relation d'approbation à AES

Les nouvelles relations d'approbation ne doivent jamais être laissées sur le chiffrement par défaut. Vérifiez l'attribut msDS-SupportedEncryptionTypes du compte de confiance inter-domaine et réglez-le sur AES uniquement (0x18) dès que chaque système s'authentifiant via la relation prend en charge AES :

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Un attribut non défini n'est pas non plus une valeur par défaut sûre à supposer dans un sens ou dans l'autre — la documentation de Microsoft indique qu'AES est pris en charge par défaut pour les contrôleurs de domaine, les contrôleurs de domaine en lecture seule et les relations d'approbation uniquement une fois que le contrôleur de domaine de déploiement est corrigé pour les changements Kerberos RC4 de 2022, et qu'une relation d'approbation ancienne ou jamais retouchée peut encore négocier RC4. TRUST_AES_DISABLED se déclenche dès que l'attribut ne signale pas la prise en charge d'AES, y compris lorsqu'il est simplement non défini. TRUST_RC4_ONLY est plus restrictif : il ne se déclenche que lorsque la relation d'approbation signale explicitement la prise en charge de RC4 sans AES, de sorte qu'un attribut simplement non défini ne le déclenchera pas.

Étape 4 — Activer le filtrage SID (quarantaine)

Le filtrage SID est activé par défaut pour les nouvelles relations d'approbation externes et de forêt, mais il est régulièrement désactivé pendant les migrations qui dépendent de sIDHistory, puis jamais réactivé. Confirmez-le explicitement :

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

TRUST_SID_FILTERING_DISABLED signale toute relation d'approbation externe ou de forêt où ce paramètre est désactivé. Ne le basculez pas à l'aveugle — si une migration en cours dépend de l'historique SID pour préserver l'accès, la quarantaine cassera cet accès jusqu'à la fin de la migration.

Étape 5 — Cadrer l'authentification sélective

L'authentification sélective transforme « tout utilisateur authentifié du côté approuvé peut tenter d'atteindre n'importe quoi de ce côté-ci » en une liste d'autorisation nommée. Activez-la sur le côté sortant de la relation d'approbation, puis accordez le droit étendu Autorisé à s'authentifier uniquement sur les objets ordinateur spécifiques que les comptes du côté approuvé doivent réellement atteindre :

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

TRUST_EXTERNAL_NO_SELECTIVE_AUTH se déclenche lorsqu'une relation d'approbation externe n'a aucune authentification sélective configurée — la lacune la plus fréquente sur les relations d'approbation mises en place pour une intégration ponctuelle avec un partenaire.

Étape 6 — Valider la relation d'approbation

Confirmez que la relation d'approbation se comporte comme l'Étape 1 le prévoyait avant de considérer le changement comme terminé :

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

Puis forcez une tentative d'authentification réelle à travers la relation d'approbation et relisez le type de chiffrement négocié avec klist. L'état de configuration et ce qui se négocie réellement sur le réseau peuvent diverger si une GPO en aval ou un membre historique outrepasse le paramètre propre de la relation d'approbation.

Détection

La création et la modification de relations d'approbation sont des événements journalisés, pas des changements silencieux — si la dérive des relations d'approbation n'apparaît que lors d'un audit périodique au lieu de déclencher une alerte, c'est le pipeline de journalisation qui pose problème, pas la visibilité.

Un seul événement prouve très peu de choses en lui-même — un 4716 qui désactive SidFilteringEnabled est habituel pendant une migration planifiée et alarmant partout ailleurs. Alertez sur l'événement, puis vérifiez-le par rapport au ticket de changement.

Remediation et checklist de durcissement

1. Inventoriez chaque relation d'approbation avec Get-ADTrust -Filter * et consignez un propriétaire, une justification métier et une date de revue pour chacune.
2. Faites correspondre la direction au besoin réel — ne conservez pas une relation bidirectionnelle là où l'authentification ne circule jamais que dans un sens.
3. Activez le filtrage SID sur chaque relation d'approbation externe et de forêt qui n'est pas activement en cours de migration.
4. Cadrez l'authentification sélective aux systèmes spécifiques dont le côté approuvé a besoin, pas au domaine entier.
5. Passez à un chiffrement AES uniquement dès que chaque système authentifiant le prend en charge.
6. Supprimez les relations d'approbation sans propriétaire ou besoin métier actuel plutôt que de les laisser « documentées » indéfiniment.

Pour la checklist complète avec le PowerShell de chaque contrôle et la correspondance conformité, voir audit du filtrage SID et de l'authentification sélective des approbations Active Directory. Pour le récit d'attaque contre lequel ces contrôles protègent, voir attaques de confiance AD : du domaine enfant à la racine de la forêt.

Cycle de vie des relations d'approbation : bidirectionnelles, transitives et inactives

Les relations d'approbation sont faciles à créer et faciles à oublier. Trois constats du catalogue ciblent précisément cette lacune de cycle de vie :

• TRUST_BIDIRECTIONAL — signale toute relation d'approbation bidirectionnelle en dehors des relations parent-enfant, par configuration, indépendamment de l'usage observé. Si le besoin métier est unidirectionnel, la restreindre à sens unique supprime un chemin d'authentification sans perte de fonctionnalité.
• TRUST_FOREST_TRANSITIVE — une relation d'approbation de forêt hérite de chaque domaine à l'intérieur de la forêt approuvée, pas seulement du domaine qui a demandé l'intégration. Avant d'approuver une relation de forêt, examinez la liste des domaines de la forêt approuvée et son hygiène administrative, pas seulement la ressource dont le demandeur a besoin.
• TRUST_INACTIVE — une relation d'approbation dont le mot de passe inter-domaine n'a pas tourné depuis plus de 180 jours. Windows fait automatiquement tourner le mot de passe d'une relation d'approbation active environ tous les 30 jours, donc un pwdLastSet ancien est un indicateur d'une relation d'approbation abandonnée que personne ne maintient plutôt qu'une mesure directe du trafic d'authentification. Une relation d'approbation inactive que personne n'utilise reste un chemin d'authentification actif que personne ne surveille. Si le besoin métier a pris fin, supprimez la relation d'approbation via le processus de changement normal plutôt que de la laisser « au cas où ».

Aucun de ces trois constats ne nécessite une compromission pour compter — ce sont des problèmes de configuration et d'hygiène de cycle de vie qui réduisent la surface d'attaque avant un incident, pas après.

Comment EtcSec détecte cela

EtcSec lit directement le bitmask trustAttributes de chaque objet TDO (Trusted Domain Object) et l'attribut msDS-SupportedEncryptionTypes du compte de confiance inter-domaine — les mêmes propriétés que Get-ADTrust et Get-ADObject exposent ci-dessus. Il signale TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY et TRUST_AES_DISABLED sur chaque relation d'approbation de l'environnement, avec des constats liés à l'objet de confiance précis afin que la remediation cible exactement la commande nécessaire.

Pour aller plus loin

Pour le récit d'attaque contre lequel ces contrôles protègent, voir attaques de confiance AD : du domaine enfant à la racine de la forêt. Pour la checklist d'audit approfondie sur le filtrage SID, l'authentification sélective et le chiffrement, voir audit du filtrage SID et de l'authentification sélective des approbations Active Directory. La rotation du mot de passe de la relation d'approbation est couverte dans rotation du mot de passe krbtgt, du compte de confiance et du mot de passe de machine du contrôleur de domaine, et le risque de délégation qui transite souvent par une frontière de confiance est couvert dans délégation Kerberos non contrainte à l'abus RBCD. Pour savoir où la revue des relations d'approbation s'inscrit dans un audit complet de l'environnement, voir audit de sécurité Active Directory : quoi vérifier d'abord et comment prouver la remediation.

Références principales

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack