Active Directory Domain Naming Best Practices

It does not matter if you are a new or experienced administrator, when you need to create a new Active Directory domain, the first question will be: what should we use for a domain name? In this article, we will discuss some key points for a network administrator planning to deploy Microsoft products, such as Exchange or Skype for Business in the corporate environment.

You have three options:

  • Option 1: Use a valid TLD (Top Level Domain, also known as routable domain) registered to your company. Some examples of this are company.ca or company.com;
  • Option 2: Use a subdomain of a valid TLD that is registered to your company. Some examples include corp.company.ca, ad.company.ca, etc.
  • Option 3: Use non-TLD name (or non-routable domain). For example, you may want to use domain.local, domain.int, or domain.corp.

Throughout this article, we are going to discuss several points where the Active Directory name will impact your production environment. From those observations, you can decide which is the best solution for your future environment.

Active Directory basic domain naming conventions

When we build the first domain controller for a new Active Directory, we are creating the first domain, but are also creating the forest which is the security boundary for the organization. Several domains can be added to help replication within the forest. A forest can be simple as a single domain forest, but can also have several trees with subdomains.

Active Directory deployment configuration

When deploying the first domain/forest, the administrator has the opportunity to define the name for that forest. It is a simple decision that sometimes can be overlooked but that may have several consequences to the future of the organization. Keep in mind that the NetBIOS name can be defined as part of the same Active Directory deployment process and it does not need to be the string of the beginning of the domain (especially for Option 3), where ad.patricio.ca could have the NetBIOS Corporate, for example.

Domain registration

It does not matter which option the administrator decides to take, but one thing is certain, the public domain must be registered based on your company’s name. This is your first step and the most important step to build a strong and solid foundation for your environment.

Depending the size of your company and its potential growth, you should plan your Active Directory infrastructure setup with the future in mind. For example, let’s say my company is Patricio Enterprises and we work only in Canada, but we are planning to have offices around the globe. In that case it is interesting to buy the Public Domains on all countries, and I would go one step further and recommend one domain to be the default one (perhaps the .com one).

Public certificates

All Public Certification Authorities do not accept non-TLDs (Option 3) or NetBIOS names on their certificates which forces the network administrator to use split-brain DNS when dealing with Exchange Server (Skype for Business also requires split-brain DNS but it allows internal PKI for the server certificate). What that means is that a DNS zone will be created in the internal network with the same name of the Public DNS zone, and internal clients will resolve the entries listed on their internal DNS servers with those entries pointing out to a local server. This also simplifies the design where we use the same name for a service for internal and external users.

From the Public Certificate perspective, there are not a lot of options. The administrator has to use the registered domain to request the certificate and accommodate the services to use such a domain (Patricio.com for example).

Domain Name Services (DNS) and name resolution design

DNS is the core service for Active Directory and key for all other Microsoft products. In the previous step, we purchased our Public Domains (valid Top Level Domain) and most of the Internet registrars provide the Public DNS console to manage the domain. As administrators, we can move that domain to a DNS provider that is specialized in managing DNS zones, or even move to Microsoft Azure/Office 365.

All configurations (DNS entries) created in the Public DNS will be available on the Internet and for the users that are outside of the internal network. In the Public DNS, the administrator will configure the settings to receive email from the Internet (MX records), and client access services for web applications, Skype for Business, webmail, and so forth.

At the end of the day, administrators want to make the end-user experience easier and as transparent as possible when the user is located either on the intranet or on the Internet. The best way to accomplish that is using a single name for the service(s) on both places. For example, webmail.patricio.com being the webmail URL for our end-users is much better than trying to explain to them that they should use webmail.ad.patricio.com (Option 2) or webmail.patricio.local (Option 3) when they are inside of the network, right?

In order to keep it simple, the utilization of a split-brain DNS is required. When using Option 1, that will be automatic because the Active Directory zone will be the same name as the Public DNS. When using Option 2 or Option 3, it requires a new zone being created (highlighted in the image). We can see the DNS and the additional split-brain zone created based on the scenario below.

Active Directory domain naming options

Based on the Microsoft design of some technologies (Skype for Business and Exchange, to name a few) the use of split-brain DNS is almost required (we do have some workarounds such as pinpoint zones. Fellow MVP Steve Goodman wrote how to configure them here).

Microsoft Exchange: Accepted domains and email address policies

When deploying the first Exchange Server which prepares the Exchange organization, as part of this process, the existent Active Directory domain will be the first SMTP address of the organization. If we are using a valid TLD (Option 1), then there is no need to create accepted domains, configure e-mail address policies, and so forth. Everything will be configured automatically, and all new mailboxes will receive the proper SMTP address without changes. Below, the Active Directory domain was created as infralab.org and Exchange picked that up as the default domain on the accepted domains which is also part of the email address policies.

Exchange admin center

Using Option 2 and Option 3 will require you to add a new Accepted Domain, then change the email address policies to use that new domain, and finally, to remove the default domain created to keep everything clean.

Microsoft Azure and User Principal Name (UPN)

When synchronizing directories between on-premises and Microsoft Azure Active Directory (AAD), the administrator must validate the public domain in Microsoft Azure, and based on that, all accounts that have that same domain set in their UPN will be synchronized with Azure Active Directory.

In the past, the standard was authentication using DOMAIN\username and it still works for internal applications. However, having SaaS (Software as a Service) and Active Directory Federation requires you to use the UPN format, which is something like [email protected],The same format is recommended when logging onto the Windows client, Skype for Business, and Exchange (when using Outlook Anywhere). When synchronizing with Microsoft Azure Active Directory, the user UPN must match the domain in Microsoft Azure.

Using Option 1, there is no additional configuration change because the default UPN is going to be the current domain or the root domain name. When using Option 2 or Option 3, the administrator has to add the valid domain in the Active Directory Domain and Trusts, and after that, make sure that all users are using the valid UPN on their user properties.

valid upn

Putting it all together

Let’s assume we register the domain patricio.com for our company. When building Active Directory, based on the options discussed, these are the items that must be addressed for each option.

Option 1: patricio.com Option 2: ad.patricio.com Option 3: patricio.local
Register the public domain Required. Registered the Patricio.com domain. Required. Registered the Patricio.com domain. Required. Registered the Patricio.com domain.
Split-Brain DNS Automatic. No additional configuration required. Patricio.com DNS zone must be created in active directory. Patricio.com DNS zone must be created in Active Directory.
Public Certificates Required. It will use the public name. Required. It will use the public name. Required. It will use the public name.*
Exchange Accepted Domains and email address policies Automatic. No additional configuration required. New accepted domain, change of e-mail address policy, and removal of the default accept domain is required. New accepted domain, change of e-mail address policy, and removal of the default accept domain is required.
Active Directory UPN Automatic. No additional configuration required. A new UPN must be added, and all users configured to use that new UPN. A new UPN must be added, and all users configured to use that new UPN.

* Well, it is not a must; however, it is strongly recommended to use a Public Certificate on Exchange/Skype for Business deployments.

The administrator that is building a new Active Directory should be looking at Option 1 and Option 2. Personally, I prefer Option 1 because it makes things easier down the road. Option 2 is doable, but it requires more changes in the environment to make it work, and from the to do list, it is almost the same as Option 3.

The takeaway of this article is to make sure to register your domain, and then make sure that you configure your Active Directory to work with the decision that you choose and plan to make it work with all other products (Public and Internal DNS, Certificates, Microsoft Azure, Exchange, Skype for Business, and so forth).

What else do you consider important when deciding an Active Directory name? Please feel free to share your comments with us.

Photo credit: darioug

About The Author

7 thoughts on “Active Directory Domain Naming Best Practices”

  1. The content of this blog post contradicts more authoritative recommendations. See these URLS’s for details:

    https://web.archive.org/web/20100106062136/http://technet.microsoft.com/en-us/library/cc738121(WS.10).aspx

    http://social.technet.microsoft.com/wiki/contents/articles/34981.best-practices-for-internal-ad-domain-and-network-names.aspx

    http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx

    http://serverfault.com/questions/76715/windows-active-directory-naming-best-practices

  2. Option 1 probably great if the particular AD domain will not be shared or part of trusted domain to other AD. Other trusted domain with VPN Connection (private connection) to the domain that uses option 1 may have trouble resolving the right server names especially Servers with private and registered public IP addresses.

  3. Currently, we are running our active directory based on option 1, and we regretted it. The reason is it is causing split-brain DNS by nature as well as if you would like your organization website to be accessible by the domain name only, it won’t because it will resolve to the AD unless you append the www.

    Best practices from Microsoft suggests that using sub-domain such as internal.example.com or ad.example.com or corp.example.com is recommended to avoid such issues.

  4. hi
    thanks for this article .
    So for more clarification .. if i decided to go with option 2, when deploying active Directory, at the “Add new forest” step the root domain should be “ad.example.com” or “corp.example.com” according to my TLD name

  5. So, to address Ibrahim’s issue above, with option 1 you can put a redirect on the web server on your DC so that http requests for the root domain are redirected to your web site.

  6. Ibrahim is referring to the problem with accessing a site using the “naked” domain, e.g. https://amazon.com instead of https://www.amazon.com. To do this you need an A record for the parent domain pointing to the web server, but domain controllers register their own “Same as parent folder” entries in the domain root. I suppose you could put up a web server on each Domain Controller with an HTTP redirect to http://www.whatever.com. But this is a really bad idea.

    In addition to the above, which is one of the more minor problems, you have a mess with private/public IPs etc. You should absolutely not use the same domain name for your Internet facing stuff and your AD, unless you are fully aware of and plan for having to manage split DNS. If you have the skill and capacity, go for it. But…why? There are very few advantages I can think of.

    Sorry Anderson, this article just doesn’t add up for me.

  7. Do not use Option one. You will have many issues to manage split brain DNS servers. It is not a best practice recommended from Microsoft

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top