Question Connexions de domaine enfants à des domaines inter-forêts


J'ai une approbation inter-forêts entre deux domaines / forêts Windows Server 2008 R2 (niveaux fonctionnels de domaine et de forêt sous Windows Server 2008 R2). Les domaines A et B sont les domaines racine de la forêt dans leurs forêts respectives et le domaine C est le domaine enfant du domaine B.

A <-> B - C

L'approbation est une approbation de forêt transitive bidirectionnelle configurée avec une authentification à l'échelle de la forêt. Quand je regarde les objets TDO dans chaque domaine, je vois que domainB a un TDO pour domainA et domainC, mais domainC a seulement un TDO pour domainB. De même, domainA a un TDO uniquement pour domainB. Je vois la même chose reflétée dans les domaines et les approbations Active Directory dans chaque domaine.

Lorsque vous sélectionnez le menu déroulant "Connexion à" sur un ordinateur domainC, seuls les domaines domainB et domainC sont répertoriés. Lorsque vous sélectionnez la liste déroulante "Connexion à" sur un ordinateur domainB, les domaines domainB, domainC et domainA sont répertoriés. Lorsque vous sélectionnez la liste déroulante "Connexion à" sur un ordinateur domainA, je ne vois que domainA et domainB répertoriés.

La résolution de noms DNS inter-forêts fonctionne entre les trois domaines via des redirecteurs conditionnels entre domainA et domainB et je peux interroger avec succès les enregistrements AD SRV dans domainA à partir de domainC et inversement.

Est-ce que je ne comprends pas la transitivité de domaine dans une fiducie inter-forêts? La transitivité ne devrait-elle pas s'étendre de domaine C à domaine A et vice versa?


modifier

Basé sur la réponse de Ryan:

J'ai commencé à penser la même chose mais je n'ai aucune expérience directe avec un trust forestier où un domaine enfant existe, je ne sais donc pas vraiment ce que je devrais voir. Même si la transivité devrait exister entre les domaines A et C, cela n'implique pas nécessairement une "visibilité". J'ai couru nltest /dclist, nltest /dsgetdc et nltest /dnsgetdc et tous reviennent avec succès des domaines A à C et vice versa. Ce qui me laisse perplexe, c'est que lorsque j'essaie d'ajouter un utilisateur à un groupe de domaine local dans le domaine A, je ne peux voir que le domaine B dans les emplacements et non le domaine C. Cela peut être le comportement attendu mais il semble étrange. Par exemple, si je souhaite ajouter un utilisateur du domaine C au groupe Domaine local du domaine Utilisateurs du Bureau à distance, le domaine AI ne peut pas y accéder car je ne vois pas le domaine C dans les emplacements du domaine A. Il n'y a aucun moyen d '"imbriquer" un domaine C utilisateur dans un groupe de domaine B, puis ajoutez le groupe de domaine B au groupe de domaine A (en raison de la portée du groupe). Donc, si je veux autoriser les utilisateurs du domaine C à se connecter aux serveurs RDS du domaine A, comment pourrais-je y parvenir?


7
2017-12-03 06:27


origine




Réponses:


Je crois que ce que vous voyez dans la liste déroulante "Se connecter à" sur un membre du domaine C est un comportement normal. Cette liste déroulante affiche uniquement les domaines adjacents (la transitive ne compte pas), mais cela ne doit pas vous empêcher de vous connecter à un membre de DomainC avec un nom d'utilisateur DomainA \ joeqwerty ou joeqwerty @ DomainA. S'il est très important pour vous de pouvoir voir DomainA dans la liste déroulante lorsque vous êtes sur un ordinateur dans DomainC, vous pourrez peut-être y parvenir avec un raccourci sécurisé.

Ce document contient quelques bonnes pépites de sagesse:

http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx

Tel que,

Limites de recherche de confiance

Lorsqu'un client recherche un chemin de confiance, la recherche est limitée à   les fiducies qui sont établies directement avec un domaine et celles qui sont   transitif dans une forêt. Un domaine enfant, par exemple, ne peut pas utiliser un   confiance externe entre son domaine parent et un domaine dans un autre   forêt. En effet, un chemin de confiance complet doit être construit   avant qu'un client puisse commencer à se frayer un chemin le long du chemin menant à un   domaine de ressources demandé. Windows Server 2003 ne prend pas en charge aveugle   les renvois; si un client ne peut pas identifier un chemin de confiance, il ne le fera pas   tenter de rechercher l'accès à une ressource demandée dans un autre domaine.   Les domaines enfants ne peuvent pas identifier les approbations externes ni les approbations de domaine à   autorités de sécurité en dehors de leur forêt parce que les TDO qui   représenter ces trusts sont publiés uniquement dans le domaine qui   partage la confiance, pas à Global Catalogs. Les clients sont donc   pas au courant de la confiance que leurs domaines partagent avec les autorités de sécurité   autres que leurs domaines parent ou enfant et ne peuvent donc pas utiliser   qu'ils aient accès aux ressources.


modifier 

Basé sur votre modification:

Par exemple, si je souhaite ajouter un utilisateur du domaine C au groupe Domaine du domaine Utilisateurs du Bureau à distance dans le domaine A, je ne peux pas y accéder car je ne vois pas le domaine C dans les emplacements du domaine A.

Cela peut paraître pédant, mais personnellement, je n’ajouterais aucun utilisateur au groupe Local Domain Domain du groupe Utilisateurs du Bureau à distance. Je nierais que des groupes de sécurité, pas des utilisateurs / comptes individuels. Les articles TechNet liés ci-dessous recommandent également l'utilisation et l'imbrication de groupes de sécurité de contrôle d'accès basés sur des rôles, en guise de meilleure pratique, plutôt que l'attribution d'autorisations pour des personnes à des ressources.

Quoi qu'il en soit, à partir du lien TechNet ci-dessous:

• Les groupes ayant une étendue locale de domaine peuvent avoir les membres suivants: comptes, groupes ayant une étendue universelle et groupes ayant une étendue globale, tous de n'importe quel domaine. Ce groupe peut également avoir comme membres d'autres groupes avec la portée locale du domaine à partir du même domaine.

Et,

Pour regrouper les utilisateurs d'une forêt nécessitant un accès similaire aux mêmes ressources dans une forêt différente, créez des groupes universels correspondant aux rôles du groupe global. Par exemple, dans ForestA, créez un groupe universel appelé SalesAccountsOrders et ajoutez les groupes globaux SalesOrder et AccountsOrder au groupe.

Deux autres choses à garder à l'esprit qui pourraient vous aider à atteindre cet objectif sont les groupes restreints à la stratégie de groupe pour ajouter le groupe souhaité aux utilisateurs du Bureau à distance et le droit d'utilisateur "Autoriser la connexion via les services Terminal Server".

Vous ne pourrez peut-être pas parcourir graphiquement les comptes de l’autre forêt au moyen d’une approbation transitive, mais taper simplement le nom de compte complet, par exemple. GroupInDomainA@DomainA.com ou DomainA\GroupInDomainA, etc.

Plus de ressources:

http://technet.microsoft.com/en-us/library/cc772808(v=WS.10).aspx

http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx


3
2017-12-04 05:17



Je pense que tu as raison Ryan. C'est une question d'adjacence, pas de transitivité. Quand j’ajoute un membre à un groupe domainA domainA, sélectionne domainB dans Emplacements et clique sur Advanced|Find Now il répertorie en fait les membres de domainB et domainC. Pour une raison quelconque, je ne voyais pas cela, probablement parce que je ne savais pas à quoi m'attendre. - joeqwerty