First published on TechNet on May 25, 2014
Tom Moser here again. Sometime last year, I wrote a post around cross-forest DCLocator and how it works. I promised a sequel and then I got busy learning 2012 R2 stuff, VMM, ADFS, Hyper-V Network Virtualization, Forza 5, Ryse, Dead Rising, etc. After some emails and comments in the last few weeks demanding a sequel, you can put away the torches and pitchforks; this will be better than Episode I.
Review
Make sure to check out the first post in this two-part series if you haven't. I'm not going to spend a lot of time on review as it covers the bases pretty well.
It's somewhat common, particularly in enterprise environments, to have multiple forests within an environment due to architecture decisions or mergers and acquisitions. Often times these newly-acquired forests will have an IPv4 address space that may have overlap. Here I'll show what happens in the event that you have an overlapping subnet between two forests, from a DCLocator perspective.
To be clear, I'm not going to cover anything involving NAT or IPv6 as we generally don't recommend using NAT for AD. For the sake of discussion, we'll just assume that the networks are fully routable, but an admin added the wrong subnet in the other forest. So let's get to it.
Setup
If you read the last post, you'll remember that we're working with two different forests here, from my lab: DMZ.milt0r.com and Corp.milt0r.com. I've established a forest trust between the two and have created a somewhat similar site topology (Figure 1) .
Figure 1 - Site Topology
Above you can see we've got the two forests, each with a few sites. CORPHQ exists in both forests, with the same 10.1.1.0/24 subnet. CORPBR also exists in both, but has conflicting subnet definitions in each forest. It appears that an administrator has set 10.50.1.0/24 on CORPBR in CORP, but hasn't set a subnet on CORPBR in the DMZ forest. Further, there's a site in the DMZ forest called "Siberia" that has the 10.50.1.0/24 subnet set.
The Client
Let's say we've got a user in the CORP forest. That user needs to access resources in the DMZ forest. For the sake of discussion, we'll assume this resource is a file server, but it applies to anything where we're doing Kerberos auth or need to bind directly to a DC, LDAP for example. Having read Part 1, you already know that when I attempt to authenticate to that DC on the other side of the trust, I'll use my own site name to construct a DNS query to find a DC.
First, this shows our client site (Figure 2) :
Figure 2 - Where...am...I?
There you can see that the client belongs to the CORPBR site in CORP.
Next, we try to connect to the resource in the DMZ. Since we're going to use Kerberos, netlogon looks for a domain controller in DMZ.milt0r.com in the site from our local forest. Looking at the DNS traffic you'll notice that DNS query contains CORPBR (Figure 3) :
Figure 3 - DNS Query for CORPBR
And immediately following, there's a DNS query for DMZDC2 (Figure 4) :
Figure 4 - DNS Query for DMZDC2
Next, we send a UDP LDAP ping to the DC and get a reply (Figure 5) :
Figure 5 - DMZDC2 Ping
That LDAPMessage is a UDP "ping" to the DC, trying to find a domain controller. As is expected, the domain controller replies in the next frame. If we examine the contents of the NetLogon response message, we see (Figure 6) :
Figure 6 - SamLogonResponse from CORPBR DC
Up until this point, everything has been exactly the same as what I described in part one. However, while we did locate a domain controller in the CORPBR site, that NetLogon reply tells the client that, since we're on a 10.50.1.0/24 subnet, we should be talking to a domain controller in the Siberia site. Based on what I've demonstrated so far, you probably know what's next: A DNS query for a DC in Siberia… and that's exactly what we get (Figure 7) .
Figure 7 - Let's find that Siberia DC
The client sends a DNS query for a DC in the Siberia site, receives a reply that DMZDC1 is the target, and then resolves the host record to an IP. Just as before, we'll send another LDAP ping (Figure 8) :
Figure 8 - Pinging...
In the first frame, the ping goes out, the DC replies and we see (Figure 9) :
Figure 9 - SamLogonResponseEx from Siberia
We've successfully bound to a DC in Siberia. Running nltest /dsgetdc, we can verify this (Figure 10) .
Figure 10 - Proof.
How does this impact me?
In part one, I demonstrated how and why having similar site names across forest trusts is important. Ensuring that there are matching site names will provide your clients with a more efficient, consistent experience when crossing forest boundaries. That said, it's also important to ensure that IP subnet ranges on your AD sites align across forest boundaries as well.
In the example above, administrators may have expected that clients would authenticate from CORPBR in CORP to CORPBR in DMZ. Instead, what we see due to the subnet conflict, is that clients end up heading off to Siberia to authenticate. If the WAN links to Siberia were slow or there happened to be insufficient domain controller capacity in Siberia, clients will have a slow, inconsistent experience. Even worse, if there are firewalls out there prohibiting access across sites, clients may end up stalled for several minutes while trying to locate a DC.
It's also important to keep in mind that this applies to networks that are unroutable or might have conflicting address space. Commonly during mergers or acquisitions, both companies will have the same IP scheme, using 10.0.0.0/8 networks. There's no way to make this work without NAT as overlapping address space won't be routable ( disclaimer: I'm not a networking expert ). Since we don't support NAT your best option is probably to merge the networks or come up with some equally not-NAT-but-still-routable plan. Ultimately, the best plan will probably not be the easiest plan, and that's merging networks and re-IP'ing devices on one side or the other. If you have a solution of your own, leave a comment!
Wrap Up
I hope that between the two posts in this series, you've got a solid understand of cross-forest DCLocator. In most cases simply matching site names across forests will solve your problems… just be on the lookout for conflicting subnet definitions and overlapping address spaces as they may cause things to behave in ways you weren't anticipating.
Until next time!
Tom "Just get a packet capture" Moser