You look at Windows Server 2012 R2 and you tell yourself: "that would be nice if I could leverage all those new features". Then you remember...
How can we do it without breaking things?
First, it is important that all applications consuming Active Directory data (for authentication as well as for data storage) are configured in a way that they are not bound to a specific DC. Being proactive means two things:
Second, we can try to detect which applications are using this kind of hardcoded configuration. This is a tough one. You cannot just look at the logs of the domain controllers because the decision of using a specific DC is done on the clients' side. So enabling LDAP logging will just basically list all your active clients without the possibility to distinguish if it comes from a hardcoded app or a regular Windows client. When replacing a DC with a new one with a new name, you might be tempted to create a DNS alias to point to the new DC. It might do the trick for the application but it's in fact just punting. You will have to maintain the DNS record. However some functionalities such as LDAPs or Kerberos could go bad with this DNS spoofing workaround. It looks like a goner...
The ldap://contoso.com illusion
It is actually also true for \\contoso.com but less relevant for the purpose of this post. When we are using the FQDN of the domain name in a connection string for an application, we could assume that we are relying only on the contoso.com DNS resolution and therefore performing a simple A lookup of the domain name (resulting of a round robin of all DC registering their LdapIpAddress record). It is not the case. Well, not always. On a Windows client, when doing a [ADSI]"LDAP://contoso.com/DC=contoso,DC=com" in a PowerShell console for example, the ADSI component, like other Windows LDAP clients are leveraging the DsGetDcName function to get the closest domain controller. It will not use this <same as parent> record that you see in your DNS console.
Give it a try:
What Are you seeing? That you are using the classic DCLocator discovery mechanism described here: http://technet.microsoft.com/en-us/library/cc759550(v=ws.10).aspx section Domain Controller Locator. So it will leverage SRV records and not the (same as parent folder) thingy you would expect."And what? Even if I was using the (same as parent folder), at the end I find and use a domain controller". Sometimes the netmask ordering was generous with you and gave you a pretty close target (see here for more info: http://support.microsoft.com/kb/842197 note that this behavior is pretty much the same for more recent versions of the OS). The problem is that you might think that because AD is highly resilient, if an application is using Active Directory pointing to its FQDN, your app inherits of that resiliency property. This is not always true. If the application is levering the Windows API to find a domain controller it is fine, if one domain controller goes down, it will find another one (there might be some timeouts depending on the app but they should be manageable). However if the application is relying on the DNS round robin of the FQDN of the domain, and the DC the app is currently pointing at goes down, because of the DNS cache, the app is likely broken. I will write another post about it. For now, I just want to bring awareness on that problem in order for you to make the verification on your apps.
Well, it's not really hope, it's more about the method. You know that Windows clients are leveraging the DCLocator process that we just talked about. It means they are using specific DNS records to localize domain controllers. Those SRV records are registered by the NetLogon service of each domain controller (there are actually also a few A records recorded by the NetLogon service such as the (same as parent folder) or some GC related ones). Without those records the DCs cannot be localized therefore cannot be used. And THAT is the trick. Here is one method:
Step by step, ooh baby
Of course, as usual, make sure you understand everything in this article and that you have a valid backup and test that in your lab first! If you are not feeling it, ask for assistance or even better: ask for a PFE!
What about NetBIOS name resolution?
Really? You also have WINS in your environment? And you are scared that your app is not only hardcoded to use the NetBIOS name of the domain but also relies on NetBIOS name resolution to discover a DC? I am sure you only wish to get rid of WINS! I will discuss this in another article. In the meantime, just make sure that the 1C record are not listing the domain controllers you want to hide. Ping me if you want more details.