IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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.
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.
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.
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!
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