Authentification inter-forêts AD - groupes manquants dans PAC

10

J'ai une configuration Active Directory composée de 2 forêts:

  • 1 forêt multi-domaines avec 1 domaine racine de forêt et 2 domaines enfants directs
  • 1 forêt à domaine unique à des fins de publication DMZ

J'ai créé 3 approbations sortantes dans le domaine DMZ, 1 approbation de forêt transitive contre le domaine racine de la forêt et 2 approbations non transitives externes (alias. Raccourcis d'approbation).

Tous les contrôleurs de domaine dans les quatre domaines sont des serveurs de catalogue global.

J'ai essayé de le visualiser ci-dessous: DMZ / Relations de confiance interne

Maintenant, voici le problème. Lorsque j'accorde l'accès à une ressource dmzRoot.tldà un groupe de sécurité du childAdomaine, cela fonctionne pour les utilisateurs de childAqui sont membres du groupe de sécurité, mais pas pour les utilisateurs du childBdomaine, même s'ils sont membres du groupe de sécurité de childA.

Disons que je veux donner à l'administrateur local l'accès à un serveur membre dans le dmzRoot.tldpar exemple. J'ajoute childA.ForestRoot.tld\dmzAdministratorsau groupe local d'administrateurs intégrés sur le serveur membre.

childA.ForestRoot.tld\dmzAdministrators a les membres suivants:

  • childA \ dmzAdmin
  • childB \ superUser

Maintenant, si je m'authentifie en tant que childA\dmzAdmin, je peux me connecter au serveur membre en tant qu'administrateur local, et si je regarde la sortie de whoami /groups, le childA.ForestRoot.tld\dmzAdministratorsgroupe est clairement répertorié.

Si je m'authentifie childB\superUsercependant, je reçois un message indiquant que le compte n'est pas autorisé pour la connexion à distance. Si je vérifie whoami /groupsle childB\superUsercompte, le childA.ForestRoot.tld\dmzAdministratorsgroupe n'est PAS répertorié.

Il semble presque que les childASID du groupe ne soient jamais inclus dans le PAC lors de l'authentification des childButilisateurs, même si tous les DC sont des GC.

J'ai désactivé la validation PAC sur la machine dans dmzRoot.tld sur laquelle je l'ai testée, mais cela n'a pas aidé.

Des suggestions sur la façon de résoudre ce problème efficacement? Comment suivre la trace de l'authentification pour déterminer où elle échoue?

active-directory windows-server-2008-r2 authentication Mathias R. Jessen
la source
2
@Lizz Bien sûr, A et B ont une confiance entre eux. Ils sont dans la même forêt.
MDMarra

Réponses:

6

Il s'avère que les raccourcis d'approbation étaient à l'origine du problème.

Lorsque l'authentification AD Kerberos parcourt les domaines, le domaine cible (c'est-à-dire dmzRoot.tld) identifie une relation d'approbation par laquelle le domaine d'origine des utilisateurs (par exemple childA.ForestRoot.tld) est un domaine approuvé.

Étant donné que la confiance de forêt transitive vers ForestRoot.tldet la confiance externe (confiance de raccourci) vers childAcorrespondent à cette condition, le domaine cible doit en choisir une, et la confiance de raccourci a priorité (car elle est explicite) sur la relation de confiance implicite dans la confiance de forêt .

Étant donné que la mise en quarantaine du filtre SID est activée par défaut sur les approbations sortantes, seuls les SID du domaine approuvé (dans ce cas, le childAdomaine) seront honorés lors de l'authentification, les SID étrangers seront filtrés.

En conclusion, il existe deux solutions:

  • Supprimez les approbations externes et comptez sur l'approbation de forêt. Étant donné que l'approbation de forêt est transitoire, tous les SID de l'ensemble de la forêt resteront dans votre jeton.
  • Désactiver la mise en quarantaine du filtre SID sur l'approbation sortante du dmzRoot.tlddomaine

J'espère que cela a du sens

Mathias R. Jessen
la source
C'est intéressant et bon à savoir. Y a-t-il une raison pour laquelle vous disposiez des fiducies de raccourci pour commencer? Vous auriez besoin d'un maximum de 1 référence, indépendamment de la topologie indiquée, était-ce un problème pour une raison quelconque?
MDMarra
1
Je pense que cela vient d'une époque où le domaine forestRoot.tld n'était pas très disponible - ou par ignorance, je ne l'ai pas conçu, j'ai simplement repris la responsabilité opérationnelle de l'environnement des équipes précédentes :)
Mathias R. Jessen
Ah, assez bien. C'est un bon cependant, qui mérite d'être mis en signet.
MDMarra
En fait, en y réfléchissant, certains des domaines enfants (l'image est une simplification excessive de ma topologie, j'ai plus de 2 domaines enfants) n'ont que des contrôleurs de domaine dans des sites loin de l'emplacement physique où se trouvent les contrôleurs de domaine dmzRoot et forestRoot. Même en supprimant simplement la nécessité d'une référence supplémentaire en raccourcissant le domaine racine de la forêt, cela aurait pu faire une différence à l'époque où les domaines enfants ont été établis, et la mise en réseau entre les sites n'était pas aussi rapide.
Mathias R. Jessen