joeware - never stop exploring... :)

I posted a quick post the other day about Third Party Active Directory Assessments raising issues that while not great, aren’t earth shattering issues. I wasn’t meaning to hang all Third Party companies out to dry, but to alert folks that they need to fully understand what the AD Assessments are really saying and don’t just depend on the verbiage provided. This stuff isn’t rocket science. You google a lot of these terms and you will get a variety of hits.

Anywho… One of the items I mentioned was Active Directory Logical Sites defined that don’t have Domain Controllers “in them”. The generally specified issue is that this configuration is against Microsoft Best Practice and causes extra unnecessary and inefficient authentication traffic.

When I see something like that in an assessment I want to slap my forehead and often do. It has really helped with my forehead wrinkles as I get up there in age and I won’t have a use for Botox for a while…

Assuming the AD Sites, AD Site Links, and Subnets are correct and properly defined, the “closest” Domain Controllers for *EVERY* domain in the forest will register DNS records for that domain in that site. Any machines that resides on a subnet assigned to that site will use those Domain Controllers (assuming they work). The location of those DCs is all done through the normal DC Locator Process and isn’t less efficient than if there is an actual DC in that site. The machine doesn’t know if the DC is in the site or not when it gets the DNS records back – there is nothing in the record to indicate that, it just gets a list of DCs it is supposed to use and it tries to use them.

There are a multitude of solid valid reasons for creating AD Sites that don’t have Domain Controllers in them, AD Sites are there to define the logical if not physical structure of the network for location of a variety of resources; not just Domain Controllers for authentication and replication. If they were only for Domain Controllers and a Site without a Domain Controller wasn’t expected or bad I wouldn’t expect DCs to handle the situation so well and properly register records and the DC Locator to find them so easily. Heck I would expect it to go even further, there would be no reason for most people to even see Sites, Site Links, and Subnets in AD and they very likely could be locked down to Admins and Domain Controllers.

I was going to write up some detailed discussion around this to further emphasize my point but I really don’t need to, it is all laid out in the DC Locator Process documentation as it is quite detailed. Read the following links if you think I am confused.

Check out

Domain Controller Locator: https://technet.microsoft.com/en-us/library/cc961830.aspx

and

Domain Controller Location Process: https://technet.microsoft.com/en-us/library/cc978011.aspx

and

Finding a Domain Controller in the Closest Site: https://technet.microsoft.com/en-us/library/cc978016.aspx

and

Fooling the DC Locator: http://blogs.technet.com/b/ad/archive/2009/01/02/fooling-the-dc-locator.aspx

Here is a hopefully simple example…

I have a single domain forest with six domain controllers spread across two sites with a third “empty” site defined and by empty I mean that it doesn’t have a DC in it.

C:\>adfind -sites -f objectclass=site -dsq | adfind -s subtree -f objectclass=server -dn -db

AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015

Using server: DNSTEST-DC1.dnstest.loc:389
Directory: Windows Server 2012 R2

BaseDN: CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC1,CN=Servers,CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC2,CN=Servers,CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

BaseDN: CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC3,CN=Servers,CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC4,CN=Servers,CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC5,CN=Servers,CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:CN=DNSTEST-DC6,CN=Servers,CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

BaseDN: CN=EmptySite,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

6 Objects returned

Or perhaps you prefer the more succinct

C:\>adfind -sites -f objectclass=site -dsq | adfind -s subtree -f objectclass=server -dn -db -stripdn

AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015

Using server: DNSTEST-DC1.dnstest.loc:389
Directory: Windows Server 2012 R2

BaseDN: CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:DNSTEST-DC1
dn:DNSTEST-DC2

BaseDN: CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
dn:DNSTEST-DC3
dn:DNSTEST-DC4
dn:DNSTEST-DC5
dn:DNSTEST-DC6

BaseDN: CN=EmptySite,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

6 Objects returned

Or if you prefer a pretty picture

The Site Links

C:\>adfind -sitelinks sitelist cost

AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015

Using server: DNSTEST-DC1.dnstest.loc:389
Directory: Windows Server 2012 R2
Base DN: CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=Site2-EmptySite,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>cost: 10
>siteList: CN=EmptySite,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>siteList: CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=Site1-EmptySite,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>cost: 80
>siteList: CN=EmptySite,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>siteList: CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=DEFAULTIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>cost: 100
>siteList: CN=Site2,CN=Sites,CN=Configuration,DC=dnstest,DC=loc
>siteList: CN=Site1,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

6 Objects returned

or

C:\>adfind -sitelinks sitelist cost -stripdn

AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015

Using server: DNSTEST-DC1.dnstest.loc:389
Directory: Windows Server 2012 R2
Base DN: CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=dnstest,DC=loc

dn:Inter-Site Transports

dn:IP

dn:Site2-EmptySite
>cost: 10
>siteList: EmptySite
>siteList: Site2

dn:Site1-EmptySite
>cost: 80
>siteList: EmptySite
>siteList: Site1

dn:DEFAULTIPSITELINK
>cost: 100
>siteList: Site2
>siteList: Site1

dn:SMTP

6 Objects returned

or

Some improperly informed consultants might think that any machine that “lives” in the subnets defined for EmptySite would randomly select a Domain Controller from all available Domain Controllers in the Domain. That is incorrect, once the client has determined what site it is in (which it will remember through reboots and update as necessary as you move around location to location) the DC Locator Process will pull the DNS entries for that site and will know EXACTLY what DCs to use. The DNS entries will come from ALL of the DCs looking at sites that aren’t covered by a DC in the site and calculate which, by virtue of the Site Link Topology, is closest and then register those DCs in that site. Again this happens for EVERY domain in the forest. So your little 5 user site down in some unheard of town in South Dakota will have DNS entries for the closest DC from the Asia Pacific Domain in the site’s DNS “zone”.  

An example of those DNS entries where the Site Links are configured such that Site 2 is “Closest” or “Lower Cost” to EmptySite:

C:\>nslookup -type=srv _ldap._tcp.emptysite._sites.dnstest.loc
Server:  localhost
Address:  127.0.0.1

_ldap._tcp.emptysite._sites.dnstest.loc SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dnstest-dc3.dnstest.loc
_ldap._tcp.emptysite._sites.dnstest.loc SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dnstest-dc5.dnstest.loc
_ldap._tcp.emptysite._sites.dnstest.loc SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dnstest-dc6.dnstest.loc
_ldap._tcp.emptysite._sites.dnstest.loc SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dnstest-dc4.dnstest.loc
dnstest-dc3.dnstest.loc internet address = 192.168.3.3
dnstest-dc5.dnstest.loc internet address = 192.168.3.5
dnstest-dc6.dnstest.loc internet address = 192.168.3.6
dnstest-dc4.dnstest.loc internet address = 192.168.3.4

The only cases where I am aware of machines using any random DC in a domain off the top of my head are

1. Machine is on an IP Address that doesn’t align to any subnet objects defined in Active Directory
2. An application requesting resolution of the domain name to an IP address outside of the Windows DNS resolution process (perhaps custom DNS lookups with non-MSFT API) and thereby bypassing the DC Locator process.

So to restate, an Active Directory Site without a Domain Controller is not a problem per se. It could be part of a problem if the Sites and Site Links aren’t intelligently configured so that the “closest” DCs properly register records in DNS for that site. However once you sort out the Site Links life should be good. If the “closest” DCs still aren’t close enough for quick-enough efficient-enough authentication, then you need to add Domain Controllers – not delete the logical AD Site.

     joe