Did you find this useful?
Socialize it today.


Choosing a Domain Name for your Active Directory

Wednesday, October 19, 2011

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.

  1. Use the same internal and external DNS domain name (internal/external: company.com).
  2. Use a different internal and external DNS domain name (internal: company.loc vs. external: company.com)
  3. 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 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 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 round robin).

There are a few ways to handle this situation:

  1. Educate your users to access the website by using the "www" record instead of the parent domain name.
  2. Install IIS on every domain controller and redirect users to the "www" page.
  3. 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://www.ITGeared.com and 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.

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 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 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.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:
Registration of gc._msdcs.dnsforestname Records in DNS Is Required
http://support.microsoft.com/default.aspx/kb/258213?p=1

Important NOTE regarding LdapIPAdress:

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

Please help us spread the word by socializing it today!

email contact us

Did you find something wrong with the information on this page? Please take a moment to report it to us so that we can continue to improve the quality of the information on this site. Click here to report an issue with this page.



Recommended Books & Training Resources

Windows Server 2008 R2 Unleashed MCITP Windows Server 2008 Enterprise Administrator: Training Kit 4-Pack: Exams 70-640 70-642 70-643 70-647