Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an Active Directory setup consisting of 2 forests:

  • 1 multi-domain forest with 1 forest root domain, and 2 direct child domains
  • 1 single-domain forest for DMZ publishing purposes

I have created 3 outgoing trusts in the DMZ domain, 1 transitive forest trust against the forest root domain, and 2 External Non-transitive trusts (aka. Shortcut Trusts).

All DC's in all four domains are Global Catalog servers.

I've tried to visualize it below: DMZ/Internal Trust relations

Now, here is the problem. When I grant access on a resource in dmzRoot.tld to a security group in the childA domain, it works for users in childA who are member of the Security group, but not for users in the childB domain, even though they are members of the security group in childA.

Let's say I want to give local administrator access to a member server in the dmzRoot.tld for example. I add childA.ForestRoot.tld\dmzAdministrators to the local builtin Administrators group on the member server.

childA.ForestRoot.tld\dmzAdministrators has the following members:

  • childA\dmzAdmin
  • childB\superUser

Now, if I authenticate as childA\dmzAdmin, I can log on to the member server as a local Administrator, and if I take a look at the output from whoami /groups, the childA.ForestRoot.tld\dmzAdministrators group is clearly listed.

If I authenticate as childB\superUser however, I get a message that the account is not authorized for remote logon. If I check whoami /groups for the childB\superUser account, the childA.ForestRoot.tld\dmzAdministrators group is NOT listed.

It almost seems like the childA group SID's never get included in the PAC when authenticating childB users, even though all DC's are GC's.

I disabled PAC validation on the machine in dmzRoot.tld that I tested it on, but this did not help.

Any suggestions as to how I troubleshoot this effectively? How do I follow the trail of authentication to determine where it fails?

share|improve this question
2  
@Lizz Of course A and B have a trust between them. They're in the same forest. –  MDMarra Mar 5 '13 at 22:09

1 Answer 1

up vote 5 down vote accepted

Turns out that the Shortcut trusts was causing the problem.

When AD Kerberos authentication travels across domains, the target realm (ie. dmzRoot.tld) identifies a trust relationship through which the users originating realm (eg. childA.ForestRoot.tld) is a trusted domain.

Since both the transitive forest trust towards ForestRoot.tld and the external trust (shortcut trust) towards childA matches that condition, the target realm has to choose one, and the the shortcut trust takes precedence (because it is explicit) over the implicit trust relationship in the forest trust.

Since SID filter quarantining is enabled on outgoing trusts by default, only SID's from the trusted realm (in this case, the childA domain) will be honoured upon authentication, foreign SID's will be filtered out.

In conclusion there are two solutions to this:

  • Remove the External Trusts, and rely on the Forest trust. Since the forest trust is transitive, all SID's from within the entire forest will remain in your token.
  • Disable SID Filter Quarantining on the outgoing trust from the dmzRoot.tld domain

Hope that made sense

share|improve this answer
    
This is interesting and good to know. Is there a reason that you had the shortcut trusts in there to begin with? You'd need a max of 1 referral regardless based on the topology shown, was that an issue for some reason? –  MDMarra Mar 5 '13 at 22:41
1  
I think it stems from a time when the forestRoot.tld domain was not highly available - or out of ignorance, I didn't design it, I simply took over ops responsibility of the environment from earlier teams :) –  Mathias R. Jessen Mar 5 '13 at 22:49
    
Ah, fair enough. This is a good one though, worth bookmarking. –  MDMarra Mar 5 '13 at 22:50
    
Actually thinking about it, some of the child domains (the picture is a gross oversimplification of my topology, I have more than 2 child domains) only has DCs in Sites far from the physical location where both the dmzRoot and forestRoot DCs are located. Even just cutting out the need for one extra referral by shortcutting the forest root domain might have made a difference back in the day when the child domains were established, and networking between locations was not as fast. –  Mathias R. Jessen Mar 5 '13 at 23:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.