Trust configuration and users enumeration

  • Last Post 23 May 2017
Techman06 posted this 18 May 2017


We have an odd Trusts configuration where a trusting forest is unable to enumerate users from a trusted domain.  It looks like this:

  • Forest "F" has a domain called
  • trusts Forest "A", Forest "B", and Forest "C" where A, B and C have created a one-way transitive Forest Level trust to, where trusts A,B,and C but A, B, and C don't trust
  • is adding users to an application share and is able to add users from Forests B and C, which works fine and as expected
  • Forest A has 3 trees in it.  The Root is a domain named which has the one-way transitive Forest trust to
    • the other trees, and both have Tree-Root transitive trusts to
  • is unable to enumerate users from to add them to the application share.  

My understanding of Tree-Root trusts is that they are treated just like parent-child trust where all parties trust one another so in theory, should be able to see user accounts from

Why can't not see user accounts from


Order By: Standard | Newest | Votes
amulnick posted this 18 May 2017

Just to make sure I follow - you're saying you can see users from but cannot see users from and both are members of the same forest with standard trusts?  


Techman06 posted this 19 May 2017

No.  Users from neither of the other trees under can be enumerated.  Would have expected that they would have been visible due to the transivity of the trust.

This can probably be solved by creating a one-way External trust from to but again, I thought it should have worked the way it is currently configured.

Apologies for the convoluted explanation.  It distinctly has the feel of the old math question, "2 trains leave their stations..."



kool posted this 19 May 2017

My memory is really foggy on this (and lots of other things), but my recollection is that for inter-forest trusts to be fully transitive the trust needs to be

between the roots of each forest. If a forest has multiple roots then one is the true master (the first domain in the forest) and should be the target of the forest trust.


The other thing that comes to mind is Global Catalogs. The roots of each forest would need to have healthy GCs. The trust partner would have to issue a referral

that the inquiring DC would need to follow. That also makes me wonder if DNS is completely healthy for all of these domains. A missing SRV record or unreachable DNS could cause problems. I presume that there would be event log entries for the lookup failure,

but with so many moving parts the challenge would be finding the domain/DC where the failure was recorded.


Can you resolve the name of a DC in the trusted domain ( from the trusting domain ( using nltest?


Yet another reason to avoid complex domain topologies… (Yes I understand that the costs of collapsing domains is quite high).





amulnick posted this 19 May 2017

Sounds like an acquisition or similar.  I can't imagine a reason for that level of complexity otherwise. :)
Any firewalls in the mix? What have you done for the health checks to date?  Results? The other forests - single domain forests, right? 


Techman06 posted this 22 May 2017

You mean people don't design things like this for fun?  :)  Yes it is a mess, but it is my mess.  Sometimes I feel like I am a glutton for punishment.

The forest level trust is with the first domain tree in the forest.  All DC's are GC's so that shouldn't be an issue.   yes, there are firewalls all over the place but those tests have so far been clean.  DNS is a good place to look at and I will check into


Thanks for the additional things to look into.

Get Outlook for Android


amulnick posted this 22 May 2017

Quick clarification - the other working trusts - they connect to single domain or multi-domain forests? 


Techman06 posted this 22 May 2017

The others are all single domain forests, which probably why they work as expected.  It seems to have something to do with the tree-root thing, even though it shouldn't based on my understanding of what the behavior should be like.


barkills posted this 22 May 2017

I’ve been following this email thread, and until this last email it didn’t click. I don’t know why that’s the case—maybe my head is in a different space today.



Anyhow, I’ll bet it’s a Kerberos name suffix routing issue. You use ‘netdom.exe trust’ to configure trusts to do route Kerberos tickets with specific name suffixes

to the correct place. is an example from our documentation, where we have ~60 domains which do 1-way trusts to But because we have an additional UPN of

user@xxxxxxxxxxxxxxxx on users in, if folks in those trusting forests want to login with

user@xxxxxxxxxxxxxxxx (instead of user@xxxxxxxxxxxxxxxx), they need to add the name suffix routing info to their side of the trust.


I’d bet for a forest with multiple tree roots it is exactly the same—the source forest needs “hints” on the trust object so it knows it can route requests for

those other tree roots to that destination trust.





Techman06 posted this 23 May 2017

You might be on to something Brian.  I'm out tomorrow but I'll take a look at that on Wednesday.  Sounds reasonable in my head too.

Thank you,



kool posted this 23 May 2017

Ack, Brian does it again! He remembers something I’ve forgotten which in this case is particularly embarrassing because I wrote netdom.


I wanted to take the source code I had written with me when I left Microsoft, both for nostalgic reasons and for reference. I didn’t though because I was concerned

that the MS lawyers might frown on it. Instead I have nothing but a poor memory to rely on. Maybe someday I can convince someone with sufficient authority in the company to let me have a copy of the code. Or perhaps it might be made open source although I’m

not holding my breath for that.