3

Short question; do all clients need to be able to talk to all domain controllers in a multi-site domain?

The background: I'm currently trying expand an existing domain to be a multi-site domain. I've done a lot of reading of the Microsoft documentation but some requirements and technicalities remain unclear to me. Everything is Windows Server 2012 R2.

To explain a bit of what we've got, we have an existing site, with 2 domain controllers in a separate management network. We then have roughly 100 client servers in separate client networks that all have access the management network that is hosting the domain controllers. Let's call this domain "int.company.com".

Now we're about to set up client servers in a second location, some of these servers will run duplicates of services from our existing site (application level DR replication will be implemented), and some of these servers will run new services. The administrators will be the same staff as the existing site, this is a remote data centre site, not a manned site.

From the various design best practices I've read sticking with a single domain seems like the best way forward given it's the same staff and running identical / similar services.

I've set up the second site with a single domain controller, and created 2 separate sites in AD Sites and Services, and assigned the correct management and client subnets to both sites. There's a permanent site to site VPN, firewall rules to allow the domain controllers to talk to each other, and dcdiag reports all is well on all 3 domain controllers. All 3 domain controllers also run AD integrated DNS servers.

However I'm struggling with connectivity for client servers at both sites. At the moment when you look up "int.company.com" it returns the IP addresses of all domain controllers at all sites, I understand from the Sites and Services documentation that client servers will always lookup their local domain controllers any way, but we also have various applications and 3rd party services using ldap against "int.company.com" which is not site aware. The current site-to-site VPN does not route traffic for client servers, only the management network for the domain controllers.

Ideally the way we'd envisaged this to work is that client servers at site A only talk to domain controllers at site A, and client servers at site B only talk to domain controllers at site B.

So back to the question, do all clients need to be able to talk to all domain controllers? Or does that mean we're better off creating a separate domain with a trust relation to provide more isolation of traffic?

Thanks in advance!

  • how did you configure the DNS servers on the "client servers", is the primary DNS server set to the DC/DNS belonging to its local site? That's how we currently do it, but I'm looking forward in reverting this and using only one site because the lowest replication interval is 15min from site2site for Active Directory changes, including DNS. – FleischKarussel May 19 '17 at 10:11
  • Yes they are pointing at the local domain controllers for DNS. That doesn't seem to stop a lookup for "int.company.com" from returning all domain controllers in all sites so there is still the potential for cross site traffic which will get blocked. – Kleborp May 19 '17 at 10:26
  • Just to clarify before I submit an answer, are the AD Joined clients working OK and resolving to a DC in the local site? is it just the non-site aware applications that are giving you the trouble? – Michael Brown May 19 '17 at 11:36
  • Yes it is just non-site aware applications that are the issue here. Examples being VMware's vCenter SSO, Jenkins build server using LDAP, etc. – Kleborp May 19 '17 at 12:28
1

Yes they do. If the domain controllers register their DNS records, any and all clients must be able to reach and use them.

If you have domain controllers that are unreachable or located in a site that you prefer clients in other sites not to use, you may configure the domain controllers to not register the DNS records. This is typical for spoke sites in a hub-and-spoke configuration.

https://support.microsoft.com/en-us/help/306602/how-to-optimize-the-location-of-a-domain-controller-or-global-catalog-that-resides-outside-of-a-client-s-site

Key: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters  
Value: DnsAvoidRegisterRecords  
Value type:  REG_MULTI_SZ  
Value Data:

LdapIpAddress
Ldap
DcByGuid
Kdc
Dc
Rfc1510Kdc
Rfc1510UdpKdc
Rfc1510Kpwd
Rfc1510UdpKpwd
GC
GcIpAddress
GenericGc
  • Thank you, I suspected as much. Basically what we want is DNS servers returning different responses depending on which site the DNS server is in. However that doesn't seem to be possible. Starting to lean towards separate domain with trust now but that brings with it some other complications. – Kleborp May 19 '17 at 12:58
1

While I don't disagree with Greg, I also didn't want to edit his answer with my thoughts on this.

Read this: https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/ - and - https://support.microsoft.com/en-us/help/247811/how-domain-controllers-are-located-in-windows -- make sure you are setting up the sites correctly and the site specific DNS records.

Your DNS lookups will not return site specific DNS records only the generic records, which is fine. And pinging the domain will only round robin those generic records.

If you have site specific DNS records and the sites and subnets are properly setup, then the clients should be using the proper local DCs first.

For your applications using actual LDAP (I'm assuming you mean that vs. just the app using AD through the OS), then you should be setting primary and secondary LDAP/DCs for these apps, not using the generic domain name for the LDAP config.

  • Thank you, sites and subnets etc. are definitely set up correctly and appears to be working (client servers correctly identify the Site they are in). We have now created manual DNS records such as <site-a>.int.storm50.com which resolves to all domain controllers in Site A and have configured LDAP based applications to use that. – Kleborp May 19 '17 at 14:01
  • @Kleborp - are you stating it is resolved now? – TheCleaner May 19 '17 at 15:08
0

Reading between the lines, there are a couple of issues at play here:

  1. Are domain clients site aware? Yes they are. The Domain Controller Locator Process will seek a Domain Controller in the site closest to the client, assuming that everything is configured correctly. This isn't the core of your question/issue though.

  2. Are applications/services site aware? DFS is site aware, Exchange Server is site aware, etc., etc., but you have applications that are not site aware. When querying the root domain, your applications receive an answer that contains all of the DNS records for all of the Domain Controllers. The Destination Address Selection algorithm detailed in RFC 6724 (which obsoletes RFC 3484) should work to "order" the list so that the record closest to the client is the one selected and used by the client (specifically by using rule 9 of the Destination Address Selection algorithm). That's the long way of saying: When a client queries the root domain and receives an answer with multiple records, the client should select the record closest to it. So even when querying the root domain, your applications should wind up communicating with the DC in their own site, or in the next closest site.

(some of my answer is cited from the links below).

https://tools.ietf.org/html/rfc6724#section-6

https://blogs.technet.microsoft.com/networking/2009/04/17/dns-round-robin-and-destination-ip-address-selection/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.