I have a cross forest trust between two Windows Server 2008 R2 domains/forests (domain and forest functional levels at Windows Server 2008 R2). Domains A and B are the forest root domains in their respective forests and domain C is the child domain of domain B.


The trust is a two-way transitive forest trust configured with forest-wide authentication. When I look at the TDO objects in each domain I see that domainB has a TDO for domainA and domainC, but domainC only has a TDO for domainB. domainA likewise has a TDO only for domainB. I see the same thing reflected in Active Directory Domains and Trusts in each domain.

When selecting the "Log on to" dropdown on a domainC computer I only see domainB and domainC listed. When selecting the "Log on to" dropdown on a domainB computer I see domainB, domainC and domainA listed. When selecting the "Log on to" dropdown on a domainA computer I only see domainA and domainB listed.

Cross forest DNS name resolution works between all three domains via conditional forwarders between domainA and domainB and I can successfully query AD SRV records in domainA from domainC and vice versa.

Am I not understanding domain transitivity in a cross forest trust? Shouldn't the transitivity extend from domainC to domainA and vice versa?


Based on Ryan's answer:

I've started to think the same thing but I have no first hand experience with a Forest Trust where a child domain exists so I don't know for sure what I should be seeing. Even though transivity should exist betweem domains A and C that doesn't neccessarily imply "visibility". I've run nltest /dclist, nltest /dsgetdc and nltest /dnsgetdc and all return successfully from domains A to C and vice versa. The thing that has me puzzled is that when trying to add a user to a Domain Local group in domain A I can only see domain B in Locations and not domain C. That may be the expected behavior but it seems odd. for instance, if I wanted to add a domain C user to the Remote Desktop Users Domain Local group in domain A I can't get there because I don't see domain C in locations in domain A. There's no way to "nest" a domain C user in a domain B group and then add the domain B group to the domain A group (because of group scope). So if I want to grant access to domain C users to log onto RDS servers in domain A how would I achieve that?

1 Answer 1


I believe what you are seeing in the "Log on to" drop-down box on a member of Domain C, is normal behavior. That drop-down box will only show the domains that are adjacent, (transitive doesn't count,) but that should not prevent you from being able to log in to a DomainC member with a username of DomainA\joeqwerty or joeqwerty@DomainA. If it's very important for you to be able to see DomainA in the drop-down box when you are on a computer in DomainC, you may be able to achieve that with a shortcut trust.

This document has some pretty good nuggets of wisdom in it:


Such as,

Trust Search Limits

When a client searches out a trust path, the search is limited to trusts that are established directly with a domain and those that are transitive within a forest. A child domain, for example, cannot use an external trust between its parent domain and a domain in another forest. This is because a complete trust path must be constructed before a client can begin to work its way along the path to a requested resource domain. Windows Server 2003 does not support blind referrals; if a client cannot identify a trust path, it will not attempt to seek access to a requested resource in another domain. Child domains cannot identify external trusts or realm trusts to security authorities outside of their forest because the TDOs that represent those trusts are published only within the domain that shares the trust, not to Global Catalogs. Clients are therefore unaware of trusts that their domains share with security authorities other than their parent or child domains, and are thus unable to use them to access resources.


Based on your edit:

for instance, if I wanted to add a domain C user to the Remote Desktop Users Domain Local group in domain A I can't get there because I don't see domain C in locations in domain A.

This may be pedantic, but I personally would not add a user to the Remote Desktop Users Domain Local group at all. I would only nest security groups in there, not individual users/accounts. The TechNet articles linked to below also recommend using and nesting role-based access control security groups as best practice rather than assigning permissions for individuals to resources.

Anyway, from the TechNet link below:

• Groups with domain local scope can have the following members: accounts, groups with universal scope, and groups with global scope, all from any domain. This group can also have as members other groups with domain local scope from within the same domain.


To group the users from one forest who require similar access to the same resources in a different forest, create universal groups that correspond to the global group roles. For example, in ForestA, create a universal group called SalesAccountsOrders and add the global groups SalesOrder and AccountsOrder to the group.

Two other things to keep in mind that might help you accomplish this goal are Group Policy Restricted Groups to add the desired group to Remote Desktop Users, and the "Allow log on through Terminal Services" user right.

You may not be able to graphically browse the accounts in the other forest by way of a transitive trust, but just type in the fully qualified account name, e.g. [email protected] or DomainA\GroupInDomainA, etc.

More resources:



  • I think you're right Ryan. It's an issue of adjacency, not transitivty. When I add a member to a domainA Domain Local group and select domainB in Locations and click Advanced|Find Now it does in fact list the members of both domainB and domainC. For some reason I wasn't seeing that, probably because I didn't know what I should expect to see.
    – joeqwerty
    Dec 10, 2014 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .