In part of the the forest authentication blog post, we’ve seen that a particular path is used depending on Kerberos or NTLM authentication. We’ve also seen that domain controllers rely on other domain controllers of the forest to find the right domain (and thus object in the AD). The question now is, which domain controller of the other forest is used to authenticate the user? What happens during a trust creation, do we really need the PDC emulator? Will LMHOSTS still help us, like it did in the old days?

Those questions we will answer in this series of authentication across trusts part 2, 3 etc..

First a little drawing about the used infrastructure for this and the next to come posts:

In the drawing above, we see two forests, rootdomain and oceanfloor. These forests are going to trust each other using a ‘normal’ trust. To establish the trust, each domain controller has a conditional forwarder for DNS setup to point to DNS servers of the other forest.

So, when we type perform an NSLOOKUP on the rootdomain domain controller to find the oceanfloor forest we get:

And from oceanfloor.local we get the IP addresses of all the domain controllers for forestroot (172.16.5.31, 172.16.5.32, 172.16.5.33, 172.16.5.34). Now although all those addresses are within the same subnet, they are split to different sites (just for this demo I’ve used /32 sites).

Figure 1: Forestroot.local Sites

Now let’s assume datacenter 1 is located in Amsterdam, datacenter 2 is located in New York, One of the branch-sites is somewhere in South Africa and the BRANCH-SITE site is a site with a Read Only domain controller. When we requested the domain name in DNS, we got ALL domain controllers including the South African one (only not the RODC). When we request the SRV records for the forestroot domain, we receive the following:

Note that all domain controllers are registered and are received.

So what does this mean?

If we do not take care of some things, for a user who is authentication over the trust, the authentication could end up on ANY domain controller (listed as above). In this example, that is nothing to worry about, since all domain controllers are well connected, but what if the OCEAN domain is closer to Datacentre 2? Can we force the cross-forest authentication towards that datacenter, so that every user that needs to be authenticated over the forests, does not cross the physical ocean WAN line?

To discover if we can force that, we need to find out, how a domain controller (in case of NTLM) or a client (Kerberos) finds domain controllers in the other domain. but off course we need to create a trust first, how is that done and how do domain controllers find each other during the creation of a trust.

When creating an external trust, it only allows for NTLM authentication. So we create a trust between the two domains, being an external trust. We open domains and trusts and create an external trust to the forestroot domain from the oceanfloor domain, while running a packet capture.

The packet capture shows something funny that has to be taken into account.

While everyone would expect the PDC to be targeted, this is NOT the case. So there we have lesson number one:

!The DNS query for domain information is NOT to the PDC service record!

And immediately we have lesson number 2:

!During the setup of a trust, the CURRENT site of the DC is looked up on the other forest BEFORE a generic query takes place!

The generic DNS service record lookup

Since our site plan of Forestroot does not have such a site, we retrieve an error back from the DNS server indicating it has no record.

Next a query for the generic service records is performed:

Now that query does receive an answer, just like we got during the NSLOOKUP manually. The response includes al domain controllers and service records like we saw before. Lesson number two can be learned here. Each service record has a priority and a weight, manipulating these weights can influence the results received and thus influence the next steps. See also Jorge’s blog for DNS optimization.

Next what we see, is that ALL LDAP domain controller srv records received are used. The OCEANFLOOR domain controller fires an LDAP lookup towards all domain controllers in the following packets.

Now comes the fun part, the FIRST domain controller to respond to this seachRequest gets to be the lucky winner and just like in the real world the other responses that come in late, are disregarded.

In my case, it’s the 172.16.6.32 that is the fastest domain controller to respond to the request with a successful lookup. Now you where probably expecting the next query to be the PDC emulator, but no, an SMB connection is tried to the 172.16.6.32 (referred to as FDC02.forestroot.local), however login failures are shown.

Note: No packets to 172.16.6.31 (FDC01.forestroot.local) that is the PDC of Forestroot.local are being sent, nor received.

But this is only the first part of the trust, we enabled the trust incoming and outgoing on the OCEANFLOOR.local domain. Now we must enable it also on the forestroot, and let us see what happens, for the time being, I’m creating the other end of the trust on the FDC02.forestroot.local. Again we see the site specific query from FDC02.forestroot.local where FDC02’s site is DATACENTER2

Dns: QueryId = 0x77C, QUERY (Standard query), Query  for _ldap._tcp.DATACENTER2._sites.dc._msdcs.OCEANFLOOR.local of type SRV on class Internet

The rest is about the same, up to the point of the SMB2 connection. This time (because the trust passwords ARE now present and the same on both ends) the connection IS successful.

So what have we learned, when we create a trust, the PDC emulators do not really come in to play, as all traffic is from domain controller to domain controller based on DNS information. We can manipulate this information to speed up the process (and optimize it), by either manipulating DNS information, OR! We add another site to our forest that has the exact site name of the site where the domain controller(s) is that we want to target!.