Authentication accross child domains

Discussion in 'Active Directory' started by Sean M. Loftus, Aug 15, 2005.

  1. I have a Windows 2003 Forest, in 2003 mode. We have 1 root domain and 2
    child domains connected to the root as separate trees. All DC are integrated
    DNS servers and there is 1 GC in each domain (not on infrast mstr). All DC
    are on the same subnet and behind a firewall. The child domains are allowed
    to communicate through the firewall for authentication traffic, DNS etc
    (389, 3268, 53, 88, 445 etc.) and the ROOT is allowed to communicate with
    all DCs in the forest unrestricted (do to them being on the same subnet) and
    do internet DNS lookups, but no client is allowed to communicate with them.
    DNS is also forwarded up through the root to resolve internet queries.

    I have a computer joined to child DomainA and a "user" from child DomainA
    using a UPN can logon without any issues. However when a "user" from child
    DomainB logs onto the same machine in child DomainA using a UPN it makes
    LDAP 389 and Kerberos 88 call to the ROOT DC's when trying to connect to SMB
    shares and changing passwords, we have verified this with packet captures.
    Because we don't allow clients to talk to the root this fails.

    Can anyone shed some light on what's going on here, I thought the GC and
    SRV records lookup would tell the child DomainA servers where the child
    DomainB services are and forward the client calls to there not the root. Is
    it because the UPN needs to do a top down lookup? Do I need a shortcut trust
    to prevent this from walking the tree to resolve calls to the other child
    domain? I've never run into this particular issue before with either version
    of AD.

    Thanks in advance for any information helping me understand this issue.

    Sean M. Loftus
    Enterprise Architect
    Loftus Consulting, Inc.
    Sean M. Loftus, Aug 15, 2005
    1. Advertisements

  2. Sean M. Loftus

    Al Mulnick Guest

    In looking at your post, it sounds like it's using the transitive trust
    mechanism to authenticate the domainb client (using domaina computer) to
    access resources. To do that, I would think a transitive trust would have
    to be used so that the kerberos authentication could succeed. I'm guessing
    that your policy doesn't allow the domaina computer to talk to domainb dc's

    Since they're part of the same forest, that would not be a surprise that the
    client would try and talk to the root in this scenario.

    Have you already seen the branch office deployment guide? I think that most
    closely matches your scenario and goals and might offer some tips as to how
    you might control the traffic differently.

    Al Mulnick, Aug 16, 2005
    1. Advertisements

  3. I'll take a look at that guide...

    I would say yes we are using the transitive trust mechanism. I've been
    thinking a shortcut trust may be in order, but I never had this problem
    before and usually the shortcut trust it to speed up slow logons that have
    to walk the tree in large forest implementations so I was hesitant to just
    put one in.

    DomainA computers "are" allowed to talk to DomainB DC's, as stated in my
    previous post all ports to the child domains are open that need to be (I may
    have neglected to list all ports in the post).

    That's why I find it strange, it should do a lookup on the local domain DNS
    for SRV records and GC for objects to do the authentication, should it not?

    DNS should do a DC to DC DNS lookup for SRV records and return them to the
    client, since the _msdcs zone is in the root I would expect that behavior,
    but why an LDAP connection?

    The client should not be waking the tree, the DC should be referring it to
    the other child domain.

    Sean M. Loftus, Aug 16, 2005
  4. Sean M. Loftus

    Al Mulnick Guest

    Al Mulnick, Aug 16, 2005
  5. Here is a good explanation of the solution:

    The actual solution to this problem is not to open the firewall to the ROOT
    Domain but provide an alternate path for the logons, i.e. a cross-link
    trust (shortcut trust) between the two child domains.

    When a Windows 2000 or Windows Server 2003 domain needs to authenticate a
    user (or otherwise verify an authentication request) to a resource that does
    not reside in its own domain, it does so in a similar fashion to DNS
    queries. Windows 2000 and Windows Server 2003 first determine whether the
    resource is located in the domain in which the request is being made. If the
    resource is not located in the local domain, the domain controller
    (specifically, the Key Distribution Service [KDC] on the domain controller)
    passes the client a referral to a domain controller in the next domain in
    the hierarchy (up or down, as appropriate). The next domain controller
    continues with this "local resource" check until the domain in which the
    resource resides is reached. (This referral process is explained in detail
    in Chapter 8.)

    Here is the article. The explanation is at the bottom of the page.

    Also look at this:

    There is a section titled "Kerberos-Based Processing of Authentication
    Requests Over Domain Trusts". This should give you a idea of what and why
    this is happening.

    Thanks for the help,
    Sean M. Loftus, Aug 16, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.