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 that 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. Proper DNS design will be
discussed in a future article.
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 http://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 where 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 22.214.171.124 (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 126.96.36.199 (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 188.8.131.52 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 four (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
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 the
http://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 because 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.
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
manually entry in DNS for those DCs that also server as the Global Catalog server. The registry entry should be created prior to the DCPROMO
To prevent a DC from registering the domain name with its IP address, create a DWORD called “RegisterDnsARecords” in this
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.1
- gc._msdcs.widgets.com A 192.168.0.2
- gc._msdcs.widgets.com A 192.168.0.3
Refer to this Microsoft article for more information:
Important NOTE regarding LdapIPAdress:
Registration of gc._msdcs.dnsforestname Records in DNS Is Required
If you are considering to prevent 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 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
Recommended Books & Training Resources