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.
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.
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).
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.
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.
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 firstname.lastname@example.org,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.
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