Few days ago my colleague at work pointed me out that I had not created a follow-up to my article about site location which was requested by some users in comments on my Polish blog. When one started this whole blogging thing one has to deal with consequences … time to write something few simples things which will allow to put more control on the process of DC location.
Let’s start with some problem statement background. It all started with a thread on Polish Windows User Group portal where discussion was around how client is locating DC and how this process will behave in a little messy environment where not all subnets are reflected in Active Directory objects which are assigned to proper subnet. As some sort of solution a supernet subnet object was created and assigned to hub localization with intent that all workstations in subnets which are not assigned to any site should use hub for authentication.
As it might look at the first glance that this idea is reasonable it is not and it might cause few problems which were actually touched in my previous post.
Network design …
For start we should take a look at network and AD objects configuration. Lets assume that we have in our network three subnets and two sites created in our directory:
- Default-First-Site (IP subnet: 192.168.1.0/24), DC –> LHFDC01
- DMZ (IP subnet: 192.168.2.0/24), DC –> LHFDC02
This left us with third subnet which is 192.168.3.0/24, which is full of workstations (as C class subnet can be 🙂 ) and is not reflected in subnet object at directory level thus it is not configured to use DC from any of our sites. Somebody has missed this detail … it happens.
So our problem is how we can control domain controller location process for clients working in this 3’rd subnet.
Some reading …
Now with this knowledge we can go to configuration part. Key to be able to control domain controller location process in such situation is to understand what roles DNS is playing in it and how we can use DNS records registration to take a control of it. Each DC by default is registering services DNS records (SRV) of two types (or purposes):
- domain wide, which allows this DC to be located by every client in a domain
- site specific which purpose is to identify particular DC as serving services in particular site.
Every client will try to determine DC which is closest to him, in particular in its site. However if client is not able to determine such DC or not able to determine its site it will query for all DCs which have registered appropriate SRV records for entire domain and will use it (this is very short description of entire process with some shortcuts 🙂 ). In case of our abandoned subnet client is not able to determine its site (bad Admin, bad) and will query for domain wide SRV records. It will be returned with two DCs:
will pick one and use it. It will work but maybe not exactly as we would want to.
Configuration part …
Lets try to fix it. Fortunately we are in control of DNS records registration process and we can use it for our purpose. In fact, in our configuration we want to prevent LHFDC02 from registering domain wide records.
What we can do is to create a new OU and put our branch office DCs there (creating OU is one of way how to achieve this – the goal is to apply GPO on DCs, so it might be site GPO as well). Then we will create new GPO object and assign it to this OU. Within this GPO an option “DC locator DNS records not registered by the DCs” has to be enabled and populated with following values “LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc”.
Now when LHFDC02 will apply this policy and will re-register its DNS records it will register only records specific to its site. For workstation working in 192.168.3.0/24 subnet it will have an effect that when this workstation will query for domain wide DC records it will be returned only with one record – LHFDC01 (In real configuration maybe we want to have more than one DC here) and it will use it.
And in this way we have solved our problem of missing subnets without causing any other problems which are being introduced by this supernet object and overlapped subnets.
What we can still think about (besides many other aspects) is SYSVOL location process … but this is topic for another post..
Little appendix …
In this post I described how we can address problem of clients working in subnets without site being assigned through configuration of DC location process. However in more proactive way one might monitor DC event log and netlogon log to identify workstations which can’t be assigned to any site, analyze this information and put correct site & subnets configuration in place. Even in some automated way … at least when it comes to identification process. Just food for thoughts … :).