Fonctionnement des relations d’approbation pour les forêts dans Active Directory (Aperçu)
Active Directory Domain Services (AD DS) assure la sécurité entre plusieurs domaines ou forêts via des relations de confiance de domaine et de forêt. Avant que l’authentification puisse se produire entre les approbations, Windows doit d’abord vérifier si le domaine demandé par un utilisateur, un ordinateur ou un service a une relation d’approbation avec le domaine du compte demandeur.
Pour vérifier cette relation d’approbation, le système de sécurité Windows calcule un chemin d’approbation entre le contrôleur de domaine (DC) du serveur qui reçoit la demande et un contrôleur de domaine dans le domaine du compte demandeur.
Les mécanismes de contrôle d’accès fournis par AD DS et le modèle de sécurité distribué de Windows fournissent un environnement pour le fonctionnement des approbations de domaine et de forêt. Afin que ces approbations fonctionnent correctement, chaque ressource ou ordinateur doit être doté d’un chemin d’approbation direct vers un contrôleur de domaine dans le domaine où il se trouve.
Le service Net Logon implémente le chemin d’approbation à l’aide d’une connexion RPC (Remote Procedure Call) authentifiée à l’autorité de domaine approuvée. Un canal sécurisé s’étend également à d’autres domaines AD DS via des relations d’approbation interdomaines. Ce canal sécurisé est utilisé pour obtenir et vérifier les informations de sécurité, y compris les identificateurs de sécurité (SID) pour les utilisateurs et les groupes.
Remarque
Domain Services prend en charge plusieurs itinéraires d'approbation de forêt, notamment une version de prévisualisation actuelle des approbations bidirectionnelles et unidirectionnelles, qui peuvent être entrantes ou sortantes.
Pour une vue d’ensemble de la manière dont les approbations s’appliquent à Domain Services, consultez Concepts et fonctionnalités de la forêt.
Pour commencer à utiliser des approbations dans Domain Services, créez un domaine managé qui utilise des approbations de forêt.
Flux de relation de confiance
Le flux de communications sécurisées sur des relations de confiance détermine l'élasticité d'une confiance. La façon dont vous créez ou configurez une approbation détermine l’étendue de la communication à l’intérieur d’une forêt, ou entre les forêts.
Le sens de l’approbation détermine le flux de communication sur les approbations. Les fiducies peuvent être unidirectionnelles ou bidirectionnelles, et peuvent être transitives ou non-transitives.
Le diagramme suivant montre que tous les domaines de Tree 1 et Tree 2 ont des relations d’approbation transitives par défaut. Par conséquent, les utilisateurs de Arborescence 1 peuvent accéder aux ressources dans les domaines de Arborescence 2 et les utilisateurs de Arborescence 2 peuvent accéder aux ressources dans les domaines de Arborescence 1, lorsque les autorisations appropriées sont affectées à la ressource.
Diagramme 
Relations de confiance unidirectionnelles et bidirectionnelles
Les relations d’approbation permettent d’accéder aux ressources de manière unidirectionnelle ou bidirectionnelle.
Une approbation unidirectionnelle est un chemin d’authentification unidirectionnel créé entre deux domaines. Dans une approbation unidirectionnelle entre Domaine A et Domaine B, les utilisateurs de Domaine A peuvent accéder aux ressources dans Domaine B. Toutefois, les utilisateurs de Domaine B ne peuvent pas accéder aux ressources dans Domaine A.
Certaines approbations unidirectionnelles peuvent être non transitives ou transitives en fonction du type d’approbation créé.
Dans une approbation bidirectionnelle, domaine A approuve domaine B et domaine B approuve domaine A. Cette configuration signifie que les demandes d’authentification peuvent être passées entre les deux domaines dans les deux sens. Certaines relations bidirectionnelles peuvent être non transitives ou transitives en fonction du type de confiance créé.
Toutes les approbations de domaine dans une forêt Active Directory Domain Services locale sont des approbations transitives bidirectionnelles. Lorsqu’un nouveau domaine enfant est créé, une approbation transitive bidirectionnelle est automatiquement créée entre le nouveau domaine enfant et le domaine parent.
Fiducies transitives et non transitives
La transitivité détermine si une confiance peut être étendue en dehors des deux domaines avec laquelle elle a été formée.
- Une approbation transitive peut être utilisée pour étendre les relations d’approbation avec d’autres domaines.
- Une approbation non transitive peut être utilisée pour refuser des relations d’approbation à d’autres domaines.
Chaque fois que vous créez un domaine dans une forêt, une relation d’approbation transitive bidirectionnelle est créée automatiquement entre le nouveau domaine et son domaine parent. Si des domaines enfants sont ajoutés au nouveau domaine, le chemin d'approbation se propage vers le haut dans la hiérarchie des domaines, étendant le chemin d'approbation initial du nouveau domaine vers son domaine parent. Les relations d’approbation transitives transitent vers le haut via une arborescence de domaine telle qu’elle est formée, créant des approbations transitives entre tous les domaines de l’arborescence de domaine.
Les demandes d’authentification suivent ces chemins d'approbation, de sorte que les comptes de n'importe quel domaine de la forêt puissent être authentifiés par un autre domaine de la forêt. Avec un processus de connexion unique, les comptes disposant des autorisations appropriées peuvent accéder aux ressources dans n’importe quel domaine de la forêt.
Fiducies forestières
Les approbations de forêt vous aident à gérer les infrastructures AD DS segmentées, et à prendre en charge l’accès aux ressources et à d’autres objets dans plusieurs forêts. Les approbations de forêt sont utiles pour les fournisseurs de services, les sociétés expérimentant fusions ou acquisitions, les extranets collaboratifs d’entreprise et les sociétés cherchant une solution d’autonomie administrative.
En vous appuyant sur les approbations de forêt, vous pouvez lier deux forêts différentes pour former une relation d’approbation transitive unidirectionnelle ou bidirectionnelle. Une approbation de forêt permet aux administrateurs de connecter deux forêts AD DS au moyen d’une seule relation d’approbation, pour fournir une expérience d’authentification et d’autorisation transparente dans les forêts.
Une relation de confiance de forêt ne peut être créée qu'entre un domaine racine de forêt dans une forêt et un domaine racine de forêt dans une autre forêt. Les confiances entre forêts ne peuvent être établies qu’entre deux forêts et ne peuvent pas être implicitement étendues à une troisième forêt. Ce comportement signifie que si une approbation de forêt est créée entre Forêt 1 et Forêt 2, et qu’une autre approbation de forêt est créée entre Forêt 2 et Forêt 3, Forêt 1 n’a pas d’approbation implicite avec Forêt 3.
Le schéma suivant illustre deux relations d’approbation de forêt distinctes entre trois forêts AD DS d’une même organisation.
Diagramme 
Cet exemple de configuration fournit l’accès suivant :
- Les utilisateurs de Forêt 2 peuvent accéder aux ressources dans n’importe quel domaine dans Forêt 1 ou Forêt 3
- Les utilisateurs de Forêt 3 peuvent accéder aux ressources dans n’importe quel domaine dans Forêt 2
- Les utilisateurs de Forêt 1 peuvent accéder aux ressources dans n’importe quel domaine dans Forêt 2
Cette configuration n’autorise pas les utilisateurs dans Forêt 1 à accéder aux ressources dans Forest 3 ou inversement. Pour permettre aux utilisateurs dans Forêt 1 et Forêt 3 de partager des ressources, une confiance transitive bidirectionnelle doit être créée entre les deux forêts.
Si une approbation de forêt unidirectionnelle est créée entre deux forêts, les membres de la forêt approuvée peuvent utiliser les ressources situées dans la forêt d’approbation. Toutefois, la confiance fonctionne dans une seule direction.
Par exemple, lorsqu’une approbation de forêt unidirectionnelle est créée entre la forêt 1 (la forêt approuvée) et la forêt 2 (la forêt d’approbation) :
- Les membres de Forêt 1 peuvent accéder aux ressources situées dans Forêt 2.
- Les membres de Forêt 2 ne peuvent pas accéder aux ressources situées dans Forêt 1 avec la même confiance.
Important
Microsoft Entra Domain Services prend en charge plusieurs directions pour les approbations de forêt.
Exigences relatives à la gestion fiduciaire forestière
Avant de pouvoir créer une approbation de forêt, vous devez vérifier que vous disposez de l’infrastructure DNS (Domain Name System) appropriée. Les approbations de forêt ne peuvent être créées que si l’une des configurations DNS suivantes est disponible :
Un serveur DNS racine unique est le serveur DNS racine pour les deux espaces de noms DNS de forêt : la zone racine contient des délégations pour chacun des espaces de noms DNS et les indicateurs racines de tous les serveurs DNS incluent le serveur DNS racine.
Lorsqu'il n'existe aucun serveur DNS racine partagé, les serveurs DNS racine de chaque espace de noms DNS de forêt utilisent des redirecteurs conditionnels DNS pour chaque espace de noms, afin de router les requêtes pour les noms dans l'autre espace de noms.
Important
Toute forêt Microsoft Entra Domain Services avec une approbation doit utiliser cette configuration DNS. L’hébergement d’un espace de noms DNS autre que l’espace de noms DNS de forêt n’est pas une fonctionnalité de Microsoft Entra Domain Services. Les redirecteurs conditionnels sont la configuration appropriée.
En l’absence de serveur DNS racine partagé, les serveurs DNS racines de chaque espace de noms DNS de forêt utilisent des zones secondaires DNS, configurées dans chaque espace de noms DNS pour router les requêtes de noms dans l’autre espace de noms.
Pour créer une approbation de forêt dans Active Directory Domain Services, vous devez être membre du groupe Admins du domaine (dans le domaine racine de la forêt), ou du groupe Administrateurs de l’entreprise dans Active Directory. Chaque approbation se voit attribuer un mot de passe que les administrateurs des deux forêts doivent connaître. Les membres administrateurs de l’entreprise dans les deux forêts peuvent créer les approbations dans les deux forêts à la fois et, dans ce scénario, un mot de passe aléatoire par chiffrement est généré et écrit automatiquement pour les deux forêts.
Une forêt de domaine managé prend en charge jusqu’à cinq approbations de forêt sortante unidirectionnelle vers des forêts locales. L’approbation de forêt sortante pour Microsoft Entra Domain Services est créée dans le centre d’administration Microsoft Entra. Un utilisateur disposant des privilèges précédemment indiqués dans l’instance Active Directory locale doit configurer l’approbation de forêt entrante.
Processus d’approbation et interactions
De nombreuses transactions inter-domaines et inter-forêts dépendent des approbations de domaine ou de forêt pour effectuer diverses tâches. Cette section décrit les processus et les interactions qui se produisent lorsque des ressources sont accessibles dans les approbations et que les références d’authentification sont évaluées.
Vue d’ensemble du traitement des références d’authentification
Lorsqu’une demande d’authentification est référencée à un domaine, le contrôleur de domaine de ce domaine doit déterminer si une relation d’approbation existe avec le domaine à partir duquel la requête vient. La direction de l’approbation et si l’approbation est transitive ou nontransitive doit également être déterminée avant qu’elle authentifie l’utilisateur pour accéder aux ressources dans le domaine. Le processus d’authentification qui se produit entre les domaines approuvés varie en fonction du protocole d’authentification en cours d’utilisation. Les protocoles Kerberos V5 et NTLM traitent les références pour l’authentification vers un domaine différemment
Traitement de la référence Kerberos V5
Le protocole d’authentification Kerberos V5 dépend du service Net Logon sur les contrôleurs de domaine pour les informations d’authentification et d’autorisation du client. Le protocole Kerberos se connecte à un centre de distribution de clés en ligne (KDC) et au magasin de comptes Active Directory pour les tickets de session.
Le protocole Kerberos utilise également des approbations pour les services d'émission de tickets multidomaines (TGS) et pour valider les certificats d'attributs de privilèges (PAC) sur un canal sécurisé. Le protocole Kerberos effectue l’authentification inter-domaines uniquement avec des domaines Kerberos de système d’exploitation non windows tels qu’un domaine Kerberos MIT et n’a pas besoin d’interagir avec le service Net Logon.
Si le client utilise Kerberos V5 pour l’authentification, il demande un ticket au serveur dans le domaine cible à partir d’un contrôleur de domaine dans son domaine de compte. Le KDC Kerberos agit en tant qu’intermédiaire approuvé entre le client et le serveur et fournit une clé de session qui permet aux deux parties de s’authentifier mutuellement. Si le domaine cible est différent du domaine actuel, le KDC suit un processus logique pour déterminer si une demande d’authentification peut être référencée :
Le domaine actuel est-il approuvé directement par le domaine du serveur dont la requête est faite ?
- Si c’est le cas, envoyez au client une référence au domaine demandé.
- Si non, passez à l’étape suivante.
Existe-t-il une relation d’approbation transitive entre le domaine actuel et le domaine suivant sur le chemin d’approbation ?
- Si c’est le cas, envoyez au client une référence au domaine suivant sur le chemin de confiance.
- Si ce n’est pas le cas, envoyez au client un message de connexion refusé.
Traitement de la référence NTLM
Le protocole d’authentification NTLM dépend du service Net Logon sur les contrôleurs de domaine pour les informations d’authentification et d’autorisation du client. Ce protocole authentifie les clients qui n’utilisent pas l’authentification Kerberos. NTLM utilise les relations de confiance pour passer des demandes d’authentification entre les domaines.
Si le client utilise NTLM pour l’authentification, la demande initiale d’authentification passe directement du client au serveur de ressources dans le domaine cible. Ce serveur crée un défi auquel le client répond. Le serveur envoie ensuite la réponse de l’utilisateur à un contrôleur de domaine dans son domaine de compte d’ordinateur. Ce contrôleur de domaine vérifie le compte d’utilisateur par rapport à sa base de données de comptes de sécurité.
Si le compte n’existe pas dans la base de données, le contrôleur de domaine détermine s’il faut effectuer l’authentification directe, transférer la demande ou refuser la demande à l’aide de la logique suivante :
Le domaine actuel a-t-il une relation d’approbation directe avec le domaine de l’utilisateur ?
- Si c’est le cas, le contrôleur de domaine envoie les informations d’identification du client à un contrôleur de domaine dans le domaine de l’utilisateur pour l’authentification directe.
- Si non, passez à l’étape suivante.
Le domaine actuel a-t-il une relation d’approbation transitive avec le domaine de l’utilisateur ?
- Si c’est le cas, transmettez la demande d’authentification au domaine suivant dans le chemin d’accès d’approbation. Ce contrôleur de domaine répète le processus en vérifiant les informations d’identification de l’utilisateur sur sa propre base de données de comptes de sécurité.
- Si ce n’est pas le cas, envoyez au client un message d’ouverture de session refusé.
Traitement Kerberos des requêtes d’authentification sur les approbations de forêt
Lorsque deux forêts sont connectées par une approbation de forêt, les demandes d’authentification effectuées à l’aide des protocoles NTLM ou Kerberos V5 peuvent être acheminées entre les forêts pour fournir un accès aux ressources dans les deux forêts.
Lorsqu’une approbation de forêt est établie pour la première fois, chaque forêt collecte tous les espaces de noms approuvés dans sa forêt partenaire, et stocke les informations dans un objet domaine approuvé. Les espaces de noms approuvés incluent les noms d’arborescence de domaine, les suffixes de nom d’utilisateur principal (UPN), les suffixes de nom de principal du service (SPN) et les espaces de noms d’ID de sécurité (SID) utilisés dans l’autre forêt. Les objets domaine approuvé (TDO) sont répliqués dans le catalogue global.
Remarque
Les autres suffixes UPN sur les approbations ne sont pas pris en charge. Si un domaine local utilise le même suffixe UPN que Domain Services, la connexion doit utiliser sAMAccountName.
Avant que les protocoles d’authentification puissent suivre le chemin d’approbation de la forêt, le nom de principal du service (SPN) de l’ordinateur de la ressource doit être résolu en un emplacement dans l’autre forêt. Un SPN peut être l’un des noms suivants :
- Nom DNS d’un hôte.
- Nom DNS d’un domaine.
- Nom unique d’un objet de point de connexion de service.
Lorsqu’une station de travail dans une forêt tente d’accéder aux données d’un ordinateur de ressource dans une autre forêt, le processus d’authentification Kerberos contacte le contrôleur de domaine pour un ticket de service vers le SPN de l’ordinateur de ressource. Une fois que le contrôleur de domaine interroge le catalogue global et détermine que le SPN ne se trouve pas dans la même forêt que le contrôleur de domaine, le contrôleur de domaine envoie une référence pour son domaine parent à la station de travail. À ce stade, la station de travail interroge le domaine parent pour le ticket de service et continue de suivre la chaîne de référence jusqu’à ce qu’elle atteigne le domaine où se trouve la ressource.
Le diagramme et les étapes suivants fournissent une description détaillée du processus d’authentification Kerberos utilisé lorsque les ordinateurs exécutant Windows tentent d’accéder aux ressources à partir d’un ordinateur situé dans une autre forêt.
diagramme 
User1 se connecte à Station de travail 1 en utilisant les identifiants du domaine europe.tailspintoys.com. L’utilisateur tente ensuite d’accéder à une ressource partagée sur FileServer1 située dans la forêt usa.wingtiptoys.com.
La StationDeTravail1 contacte le KDC Kerberos sur un contrôleur de domaine de son domaine, le CDEnfant1, et demande un ticket de service pour obtenir le SPN du ServeurDeFichiers1.
ChildDC1 ne trouve pas le SPN dans sa base de données de domaine et interroge le catalogue global pour voir si des domaines de la forêt tailspintoys.com contiennent ce SPN. Étant donné qu’un catalogue global est limité à sa propre forêt, le SPN n’est pas trouvé.
Le catalogue global consulte ensuite sa base de données pour obtenir des informations sur les approbations de forêt établies avec sa forêt. S’il en trouve, il compare les suffixes de nom figurant dans l’objet TDO de l’approbation de forêt au suffixe du SPN cible pour trouver une correspondance. Une fois qu’une correspondance est trouvée, le catalogue global fournit un indicateur de routage vers ChildDC1.
Les indicateurs de routage aident à diriger les demandes d’authentification vers la forêt de destination. Les indicateurs sont utilisés uniquement lorsque tous les canaux d’authentification traditionnels, tels que le contrôleur de domaine local, puis le catalogue global, ne parviennent pas à localiser un SPN.
Le CDEnfant1 renvoie une référence pour son domaine parent à la StationDeTravail1.
La StationDeTravail1 contacte un contrôleur de domaine dans le CDRacineDeForêt1 (son domaine parent) pour obtenir une référence à un contrôleur de domaine (CDRacineDeForêt2) dans le domaine racine de forêt de la forêt wingtiptoys.com.
La StationDeTravail1 contacte le CDRacineDeForêt2 dans la forêt wingtiptoys.com pour obtenir un ticket de service vers le service demandé.
Le CDRacineDeForêt2 contacte son catalogue global à la recherche du SPN ; le catalogue global trouve une correspondance pour le SPN et la renvoie au CDRacineDeForêt2.
Le CDRacineDeForêt2 retourne ensuite la référence vers usa.wingtiptoys.com à la StationDeTravail1.
La StationDeTravail1 contacte le KDC sur le CDEnfant2 et négocie le ticket pour que l’Utilisateur1 puisse accéder au ServeurDeFichiers1.
Une fois que la station de travail Workstation1 dispose d’un ticket de service, elle envoie le ticket de service à FileServer1, qui lit les informations d’identification de sécurité de User1et construit un jeton d’accès en conséquence.
Objet de domaine approuvé
Un objet de domaine approuvé (TDO) stocké dans le conteneur Système de son domaine représente chaque domaine ou approbation de forêt au sein d’une organisation.
Contenu TDO
Les informations contenues dans un objet TDO varient selon que cet objet a été créé par une approbation de domaine ou par une approbation de forêt.
Lorsqu’une approbation de domaine est créée, les attributs tels que le nom de domaine DNS, le SID de domaine, le type d’approbation, la transitivité de confiance et le nom de domaine réciproque sont représentés dans le TDO. Les objets TDO d’approbation de forêt stockent des attributs supplémentaires pour identifier tous les espaces de noms approuvés à partir de la forêt partenaire. Ces attributs incluent les noms d’arborescence de domaine, les suffixes UPN (User Principal Name), les suffixes SPN (Service Principal Name) et les espaces de noms SID (Security ID).
Étant donné que les approbations sont stockées dans Active Directory en tant qu’objets TDO, tous les domaines d’une forêt ont connaissance des relations d’approbation qui sont en place dans toute la forêt. De même, lorsque deux ou plusieurs forêts sont jointes par l’intermédiaire d’approbations de forêt, les domaines racines de forêt dans chaque forêt ont connaissance des relations d’approbation qui sont en place dans tous les domaines des forêts approuvées.
Modifications du mot de passe TDO
Les deux domaines d’une relation d’approbation partagent un mot de passe, qui est stocké dans l’objet TDO dans Active Directory. Dans le cadre du processus de maintenance du compte, tous les 30 jours, le contrôleur de domaine approuvé modifie le mot de passe stocké dans le TDO. Toutes les relations de confiance bidirectionnelles sont en fait deux relations de confiance unidirectionnelles allant dans des directions opposées ; le processus se produit donc deux fois pour les relations de confiance bidirectionnelles.
Une approbation comprend une partie d’approbation et une partie approuvée. Dans la partie approuvée, tout contrôleur de domaine accessible en écriture peut être utilisé pour le processus. Dans la partie d’approbation, l’émulateur de contrôleur de domaine principal procède à la modification du mot de passe.
Pour modifier un mot de passe, les contrôleurs de domaine effectuent le processus suivant :
L’émulateur de contrôleur de domaine principal dans le domaine d’approbation crée un nouveau mot de passe. Un contrôleur de domaine dans le domaine approuvé n’initie jamais la modification du mot de passe. Elle est toujours initiée par l’émulateur de contrôleur de domaine principal du domaine d’approbation.
L’émulateur de contrôleur de domaine principal dans le domaine d’approbation définit le champ OldPassword de l’objet TDO sur le champ NewPassword actuel.
L’émulateur de contrôleur de domaine principal dans le domaine d’approbation affecte le nouveau mot de passe au champ NewPassword de l’objet TDO. La conservation d’une copie du mot de passe précédent permet de revenir à l’ancien mot de passe si le contrôleur de domaine du domaine approuvé ne parvient pas à recevoir la modification, ou si la modification n’est pas répliquée avant qu’une demande ne soit effectuée qui utilise le nouveau mot de passe d’approbation.
L’émulateur de contrôleur de domaine principal dans le domaine d’approbation effectue un appel distant à un contrôleur de domaine dans le domaine approuvé, afin de lui demander de définir le mot de passe du compte d’approbation sur le nouveau mot de passe.
Le contrôleur de domaine dans le domaine approuvé remplace le mot de passe d’approbation par le nouveau mot de passe.
Dans chaque relation de confiance, les mises à jour sont répliquées vers les autres contrôleurs de domaine du domaine. Dans le domaine de confiance, la modification déclenche une réplication urgente de l’objet de domaine approuvé.
Le mot de passe est maintenant modifié sur les deux contrôleurs de domaine. La réplication normale distribue les objets TDO aux autres contrôleurs de domaine du domaine. Toutefois, il est possible que le contrôleur de domaine dans le domaine d’approbation modifie le mot de passe sans mettre à jour correctement un contrôleur de domaine dans le domaine approuvé. Ce scénario peut se produire parce qu’un canal sécurisé, nécessaire pour traiter la modification du mot de passe, n’a pas pu être établi. Il est également possible que le contrôleur de domaine dans le domaine approuvé ne soit pas disponible à un moment donné pendant le processus et ne reçoive pas le mot de passe mis à jour.
Pour gérer les situations dans lesquelles la modification du mot de passe n’est pas correctement communiquée, le contrôleur de domaine dans le domaine d’approbation ne modifie jamais le nouveau mot de passe, sauf s’il a correctement authentifié (configurer un canal sécurisé) à l’aide du nouveau mot de passe. Ce comportement est la raison pour laquelle les mots de passe anciens et nouveaux sont conservés dans l’objet TDO du domaine d’approbation.
Une modification de mot de passe n’est pas finalisée tant que l’authentification à l’aide du mot de passe réussit. L’ancien mot de passe stocké peut être utilisé sur le canal sécurisé jusqu’à ce que le contrôleur de domaine du domaine approuvé reçoive le nouveau mot de passe, ce qui permet un service ininterrompu.
Si l’authentification utilisant le nouveau mot de passe échoue, car le mot de passe n’est pas valide, le contrôleur de domaine d’approbation tente de s’authentifier à l’aide de l’ancien mot de passe. S’il s’authentifie correctement avec l’ancien mot de passe, il reprend le processus de modification du mot de passe dans les 15 minutes.
Les mises à jour de mots de passe pour la relation d'approbation doivent être répliquées aux contrôleurs de domaine des deux côtés de la relation d’approbation dans un délai de 30 jours. Si le mot de passe d'approbation est modifié après 30 jours et qu'un contrôleur de domaine n'a que le mot de passe N-2, il ne peut pas utiliser l’approbation du côté de la partie confiante et ne peut pas créer un canal sécurisé du côté de la partie approuvée.
Ports réseau utilisés par les approbations
Étant donné que les relations de confiance doivent être déployées à travers différentes frontières réseau, elles peuvent s'étendre sur un ou plusieurs pare-feu si nécessaire. Lorsque c’est le cas, vous pouvez soit tunneliser le trafic d’approbation sur un pare-feu, soit ouvrir des ports spécifiques dans le pare-feu pour permettre au trafic de passer.
Important
Les services de domaine Active Directory ne prennent pas en charge la restriction du trafic RPC Active Directory vers des ports spécifiques.
Pour en savoir plus sur les ports nécessaires dans une approbation de forêt, consultez la section Windows Server 2008 et versions ultérieures de l’article du Support Microsoft Guide pratique de configuration d’un pare-feu pour les domaines et les approbations Active Directory.
Services et outils de prise en charge
Pour prendre en charge les approbations et l’authentification, certaines fonctionnalités et outils de gestion supplémentaires sont utilisés.
Ouverture de session réseau
Le service Net Logon gère un canal sécurisé d’un ordinateur Windows vers un contrôleur de domaine. Il est également utilisé dans les processus suivants liés à la confiance :
Configuration et gestion de l’approbation : Net Logon permet de conserver les mots de passe d’approbation, de collecter des informations d’approbation et de vérifier les approbations en interagissant avec le processus LSA et le TDO.
Pour les approbations de forêt, les informations d’approbation incluent l’enregistrement des informations d’approbation de forêt (FTInfo) ; celui-ci comprend l’ensemble des espaces de noms qu’une forêt approuvée entend gérer, annoté à l’aide d’un champ indiquant si chaque revendication est approuvée par la forêt d’approbation.
Authentification : fournit les informations d’identification de l’utilisateur sur un canal sécurisé à un contrôleur de domaine et retourne les SID de domaine et les droits utilisateur pour l’utilisateur.
Emplacement du contrôleur de domaine : aide à rechercher ou à localiser des contrôleurs de domaine dans un domaine ou sur plusieurs domaines.
Validation directe : les informations d’identification des utilisateurs d’autres domaines sont traitées par Net Logon. Lorsqu’un domaine d’approbation doit vérifier l’identité d’un utilisateur, il transmet les informations d’identification de l’utilisateur via Net Logon au domaine approuvé pour vérification.
Vérification pac (Privilege Attribute Certificate) : lorsqu’un serveur utilisant le protocole Kerberos pour l’authentification doit vérifier le pac dans un ticket de service, il envoie le pac sur le canal sécurisé à son contrôleur de domaine pour vérification.
Autorité de sécurité locale
L’autorité de sécurité locale (LSA) est un sous-système protégé qui conserve des informations sur tous les aspects de la sécurité locale sur un système. Collectivement appelé stratégie de sécurité locale, le LSA fournit différents services pour la traduction entre les noms et les identificateurs.
Le sous-système de sécurité LSA fournit des services en mode noyau et en mode utilisateur pour valider l’accès aux objets, vérifier les privilèges utilisateur et générer des messages d’audit. LSA est responsable de la vérification de la validité de tous les tickets de session présentés par les services dans des domaines approuvés ou non approuvés.
Outils de gestion
Les administrateurs peuvent utiliser Active Directory Domaines et Approbations, Netdom et Nltest pour exposer, créer, supprimer ou modifier des approbations.
- Domaines et approbations Active Directory est la console MMC (Microsoft Management Console) qui est utilisée pour gérer les approbations de domaine, les niveaux fonctionnels de domaine et de forêt et les suffixes de nom d’utilisateur principal.
- Les outils en ligne de commande Netdom et Nltest peuvent être utilisés pour rechercher, afficher, créer et gérer les approbations. Ces outils communiquent directement avec l’autorité LSA sur un contrôleur de domaine.
Étapes suivantes
Pour prendre en main la création d’un domaine managé avec une approbation de forêt, consultez Créer et configurer un domaine managé Domain Services. Vous pouvez ensuite créer une approbation de forêt sortante vers un domaine local.