Sites Sites Everywhere…

…Without a DC to spare! Hey all, this is Sean. You may remember me from a few old ADFS posts. I’m no longer on the Directory Services team but I still do a lot of DS stuff in Premier Field Engineering (PFE). Anyway, I recently ran into a few “interesting” site topologies while in the field. I want to discuss them with you and explain their impact on automatic site coverage.

When was the last time you created a site? Have you noticed that you can’t click OK until you select a site link to associate with the site?

Figure 1

Figure 2

There’s a reason for this: even if a site has no domain controller in it, a site link is necessary between it and other sites. Domain Controllers cannot calculate site coverage without all of the sites being “linked” with site links. Unfortunately, once the site is created and added to a site link, you can remove it. Nothing will check to see if it’s contained in another site link first; that’s up to you.

To understand this and its impact, let’s talk about a few other concepts.

DNS

Ah DNS. As DNS goes, so goes AD. There’s no way I can explain everything you need to know about DNS here, but I urge you to eat your TechNet Wheaties and read this document from top to bottom:

How DNS Support for Active Directory Works
https://technet.microsoft.com/en-us/library/cc759550(WS.10).aspx

For our purposes, there are a few things I want to make sure you’re aware of. First, the Netlogon service on a domain controller is responsible for registering SRV records. These SRV records are what clients use to find services such as LDAP or Kerberos. DC’s register generic and site specific SRV records. A simple DNS structure would look something like this:

Figure 3

These are generic records. They are not associated with any site in Active Directory.

Figure 4

These are site-specific records. It is very inefficient for a client computer to have to talk to a DC outside of its own site for client logon and Active Directory searches. For more on optimal Site Topology design, please click here.

The site specific records help clients find DCs offering the services they’re looking for that are closest to them.

So how does that work? Enter the DCLocator…

DCLocator

I’m a client and I need to authenticate to a domain controller. How do I find a domain controller to authenticate me? To get the full details check out this link. I’ll give you a quick summary:

Basically, it goes like this:

1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
2. DNS server returns list of DC’s.
3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
4. DC returns…
   1. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
   2. The site that the current domain controller is in.
   3. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
5. The client decides whether to use the current DC or to look for a closer option.
   1. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
   2. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._ sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.

Automatic Site Coverage

Great, so now we know a little about DNS and DCLocator. Without the site specific query, clients would access domain controllers randomly instead of the ones closest to them. Now let’s talk about the sites you have setup. Are they exclusively for AD? Maybe, but I’m guessing you have some sites without DCs for Configuration Manager or other Active Directory aware applications. Take the following site configuration for example:

Figure 5

Figure 6

I’ve got 5 sites configured, HQ and Branch1 through 4. On the right you can see the site links I have created. HQ is my hub and each branch is setup with HQ in a site link…except 4. Also notice there are no domain controllers in Branch3 or Branch4.

In this case, there are no DCs in Branch3. If I’m a client in Branch3, how do I know which domain controller to authenticate against? It’s no different, I still query DNS to see which DC is in that site. To keep me from picking a random DC somewhere in the forest, the DCs perform automatic site coverage. Every domain controller in the forest follows this procedure:

1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
2. Build a list of candidate sites — sites that have domain controllers for this domain.
3. For every target site, follow these steps:
   1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
   2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
   3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
   4. If more than one, break ties by choosing the site that is first alphabetically.
   5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

That’s straight from the “How DNS Support for Active Directory Works” article listed in the DNS section. Notice I highlighted point “B”. Here it is, the reason I wanted to blog about this “…build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.) ”. Basically we’re saying that if the site that has no domain controller has no “lowest site link cost” then do NOTHING! Whaddya know, that’s exactly what happens:

Figure 7

Do you see site “Branch4” listed in DNS anywhere? Nope, because it’s not part of any site link! What does this mean? Any client trying to do a site specific operation from Branch4 will ultimately end up using any domain controller instead of a domain controller closest to it based on site topology. This isn’t good! It’s as if a site and subnet is not defined for a client. In some regards it’s worse because we don’t log this information like we do about clients authenticating from undefined subnets. This would also cause problems with DFS site costed referrals (which all of your DC’s should have enabled - starting in Windows Server 2008 it is always enabled by default if the registry value is not set).

Need some help with this? Ok. but only because PowerShell is so awesome!

First things first:

Launch Powershell

You’ll need the “activedirectory” module.

import-module activedirectory

Now let’s get to the meat of this thing and get all of the sites listed in site links:

$site_links = get-adobject -filter 'objectclass -eq "sitelink"' -searchbase 'cn=configuration,dc=contoso,dc=com' -properties sitelist | foreach {$_.sitelist} | sort | get-unique

The first part of this command uses “get-adobject” to return the sitelist property of each site link. We then pipe it to “foreach” to get a list of the sites. Next we pipe that list to “sort”. Now we take that sorted list and pipe it to “get-unique”. This is necessary because different site links could contain the same sites (for example, site HQ is contained in each of my site links because it’s my hub). Finally we take this sorted, unique list of sites found in all of the site links and stuff them in a variable called $site_links:

Figure 8

Next we need to get a list of sites:

$sites = get-adobject -filter 'objectclass -eq "site"' -searchbase 'cn=configuration,dc=contoso,dc=com' -properties distinguishedname | foreach {$_.distinguishedname} | sort

Here we use the same “get-adobject” but return the DN of each site. Next we pipe it to “foreach” to get our list, and then “sort” to get a sorted list. We don’t have to worry about duplicates here since you can’t create two sites with the same site name. In the end, $sites will contain this information from my lab:

Figure 9

Finally, we use “compare-object” to compare $site_links to $sites.

Compare-object -referenceobject $site_links -differenceobject $sites

This will return the differences between the two objects. As we can see, the only difference is site Branch4:

Figure 10

This means Branch4 is a site not contained in any site link. As I indicated earlier in the post, this could effectively cause a client computer to make inefficient queries to domain controllers that are not even close to its own site. If you have a computer that is having latency issues and a SET L reveals that the domain controller that authenticated the user is on the other side of the planet, you may need to get a report on your AD Sites and configure them optimally.

Ok, now seriously, go check ’em …

Sean “my shoe size would be 60 in Europe” Ivey