It is a really important step in the planning phase when considering what Active Directory (AD) Domain Name to select. This is especially true when administrators find themselves in a situation where a bad name choice was made and now they may be considering a domain name rename.
That is a really bad situation to be in, even though a domain name rename is supported as of AD 2003. Generally, there are three choices to pick when deciding which name to use:
- Use the same internal and external DNS domain name (internal/external: company.com).
- Use a different internal and external DNS domain name (internal: company.loc vs. external: company.com)
- Use a sub-domain of the external DNS domain name for the internal namespace (internal: int.company.com vs. external: company.com).
For this article, we are going to assume that you decided on option #1. Personally, I find the first option to be the best, even though it is least recommended by Microsoft. The main reason why it is not recommended is that if you are not very familiar with DNS administration, it is possible to expose your Active Directory records to the Internet.
However, if you design the infrastructure correctly, you will transparently provide services to your internal and external users accessing resources using the same domain name.
I have experienced firsthand this “gotcha” back with my first implementation of Active Directory using the same internal and external name. The problem was with internal users accessing the company’s website using the same domain name. For example, let’s say that the domain name is “widgets.com”.
Our DNS administrators correctly separated the DNS environment so that a dedicated external DNS infrastructure supports the external Internet traffic, while the internal DNS infrastructure supports the Active Directory infrastructure. However, when internal users open a browser and type widgets.com, they are only able to access the web page a certain percentage of the time. Most of the time, the users would simply get a “Page Not Found”.
While researching this issue, I noticed that the Domain Controllers in the widgets.com domain were registering a blank, “parent record” for the domain name with the IP address of each DC. This is the default behavior of Active Directory Domain Controllers. This record is actually called the LdapIPAddress. Therefore, the internal DNS zone for widgets.com had the following records:
- widgets.com
65.85.0.1(Public IP for website, simply an example) - widgets.com
192.168.0.1 - widgets.com
192.168.0.2 - widgets.com
192.168.0.3 - www.widgets.com
65.85.0.1(Public IP for website)
As you may notice in this example, the private IPs 192.168.0.1-3 belong to the Domain Controllers. The 65.85.0.1 is the public IP of the external web server, created by the DNS Administrator. In this scenario, when a request would come into the internal DNS server for “widgets.com”, the DNS server would respond with the 4 records.
Then your browser would connect on the first IP that it resolved the name to. In this hypothetical scenario, you would expect that only 25% of your internal users would be able to access the website (25% because of DNS round robin).
There are a few ways to handle this situation:
- Educate your users to access the website by using the “www” record instead of the parent domain name.
- Install IIS on every domain controller and redirect users to the “www” page.
- Prevent the DCs from updating the
LdapIPAddress.
Educate your users
Educating users may be challenging to do. In addition, in larger environments, this task becomes too difficult to keep up with because of the turn-around of employees.
Also, non-technical users really don’t understand the difference between https://www.ITGeared.com and https://ITGeared.com, so even if you educate them, they will most likely try either record until a page is displayed.
Install IIS on DCs
The second method of installing IIS on the DCs will easily mitigate this issue. The reason is that if the client resolves the domain name to the IPs of the DCs, the client will access the web services installed on the DCs.
All you would need to do is either redirect the user via native IIS tools or create a default page that redirects the user programmatically.
Registry Edits
The third method can work very well in situations where security policies do not allow IIS to be installed on Domain Controllers. Preventing the LdapIPAddress from registering in DNS can be an easy fix.
But it does require a manual entry in the registry of each domain controller and a manual entry in DNS for those DCs that is also server as the Global Catalog server. The registry entry should be created prior to the DCPROMO process.
To prevent a DC from registering the domain name with its IP address, create a DWORD called RegisterDnsARecords in this location: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
This DWORD specifies whether the domain controller registers Domain Name System (DNS) A (address) records for the domain. If the domain controller is a global catalog resource, then this entry also determines whether the domain controller registers DNS A records for the global catalog.
A value of 0 will not allow the DC to register these records (domain name and GC record if applicable), and a value of 1 will allow the DC to register the records.
Since this also prevents the DC from registering the GC record in DNS, you will also have to create that record manually in the AD DNS zone. In our example, this record would be required for each DC that you modified the registry on. We will assume that all DCs in this example are also Global Catalog servers.
gc._msdcs.widgets.com A 192.168.0.1gc._msdcs.widgets.com A 192.168.0.2gc._msdcs.widgets.com A 192.168.0.3
Important NOTE regarding LdapIPAdress
If you are considering preventing this record from being registered in DNS, there are some implications that may impact your ability to locate certain services in the domain. You should be fully aware of what these implications are and how to overcome them.
Read more about LdapIPAdress
AD DS: This domain controller must register its DNS host (A/AAAA) resource records for the domain: http://technet.microsoft.com/en-us/library/dd378858(WS.10).aspx
