One of the subjects that doesn’t get a whole lot of coverage in IT is how to name an Active Directory domain. There’s a lot of confusion around the how and why to name a Domain primarily because the best practices for doing so have changed a number of times over the past decade or so. A short discussion I got into on my last post prompted me to go into a good bit more depth on this subject, since it’s something there is a lot of misunderstanding about.
There are currently two basic strategies that are in common practice when IT administrators and systems engineers decide on their domain names.
- Use an Internal private domain name
- Use an External Public domain name
An Internal Private domain name would be something like domain.local or company.internal. A private domain is essentially just a domain that is not publicly available on the Internet. This is because the .internal and .local are not Top Level Domains (TLDs) that are recognized by the Internet Corporation for Assigned Names and Numbers (ICANN), which is the organization that regulates domain names and IP addresses on the Internet. Because ICANN doesn’t recognize internal TLDs, no public DNS servers have zones that include them, so there is no way a domain that uses domain.local or company.internal can be resolved to an IP address on the public Internet.
An External Public domain name is something like domain.com or company.net. These are domain names that use TLDs recognized by ICANN and that can be resolved by public DNS servers.
What most people don’t know, however, is that Microsoft doesn’t really recommend either of these strategies for domain naming any longer. Before I explain what the new recommendations from Microsoft are, I’ll explain what the traditional pros and cons of these strategies are as well as a little history about them, in case you end up in an environment that uses these strategies, since my main purpose with this blog is to help people understand best practices and why they’re best practices rather than just telling people what they are.
Public Domains in Active Directory
Using a public domain for your Active Directory Domain Name may seem like a great idea if you own a public domain (which, now, is most businesses). However, there are some distinct disadvantages to doing so. Microsoft used to recommend that businesses avoid using their public domain name for their Internal domain for a lot of reasons.
The big reason to avoid using the same domain name internally and externally is a phenomenon known as Split DNS. Split DNS is where you have two completely separate DNS servers or server groups managing the exact same DNS Forward Lookup Zone. Split DNS isn’t necessarily a bad thing, but it does greatly increase the administrative burden of managing DNS. This is because you have to create a new record on both DNS servers every time you add a new server if you want it to be accessible publicly and privately. Active Directory also throws an additional wrench into this because domain.com is always reserved as a host name for discovering Domain Controllers. If you have an external DNS server that uses domain.com as an A record to a web server, that web server will never be directly accessible from inside your network.
Even more annoying, though, is the possibility that you might end up with a host name that points to a completely different server externally and internally. In this situation, users that go to www.company.com when outside the company network would be forwarded to one web server (Say, a public web page for the general public), and users that go there while inside the company network would go to a different server (An Intranet Publication site, for instance). In this situation, a user that connects to the company network by VPN would actually have the public web page stuck in their DNS cache and would be unable to access the Intranet Publication site without clearing their DNS cache. I’ve seen this happen in a couple of different environments and it results in a lot more helpdesk calls than is necessary, which in turn costs the company a lot of money.
Private Domains in Active Directory
Because of the limitations inherent in using Public domains for Active Directory, Microsoft recommended using Private domains when selecting an Active Directory Domain name from the release of Windows 2000 til about 2007. With a private internal domain, there is no need to manage Split DNS. Users would connect to external DNS servers when they wanted to access the servers on the public Internet and connected to internal DNS servers when accessing internal resources without any need to manage multiple DNS zones. It was also thought that using a private domain added a level of security, since no one outside the company would know the domain name for the internal network. This, of course, is just security through obscurity, and doesn’t really provide much security at all (if any). Because of the decreased administrative burden and presumed added security, administrators have used Private domain names for Active Directory for well over a decade now.
Big Changes, the Future is Now
But, as things so often do, technology has changed significantly and Microsoft made a number of changes to their products that necessitated changes to their best practices. One of the biggest changes to Microsoft’s solution base was Exchange 2007.
Exchange 2007 represented a massive paradigm shift in Microsoft’s Email platform. It was vastly different from all other Exchange versions before it, primarily because the needs of the corporate world changed drastically between the release of Exchange 2003 and 2007. Email needed to be more secure, and Microsoft was working toward the now burgeoning world IT automation. One of the most important new automation features that Exchange 2007 introduced was Autodiscover.
Autodiscover allowed users to configure their mail clients without having to enter server names, user names, and all that other stuff that got in the way of users and their email and resulted in loads of extra work for IT support personnel. All it required was an entry in DNS to allow the mail client to reach an XML file that contained all the necessary settings and the client could then use those settings to set itself up without user interaction. However, the mechanism that controlled that caused some conflict with the existing best practices for Active Directory Domain Naming. In order to work, Autodiscover required SSL certificate validation, and Exchange automatically configured itself to use a the Active Directory domain name as the server name to use for automatically configuring clients on the internal network, and with the best practice of using private domain names, that meant that you had to reconfigure Exchange to point clients to the whatever name was on the SSL certificate for the server. If you didn’t do this, clients would get certificate error messages when they used a mail client (For more details on that, read my blog bost here: http://acbrownit.wordpress.com/2012/12/20/internal-dns-and-exchange-autodiscover/).
The problems with autodiscover were actually pretty simple to solve with the use of certificates that supported Subject Alternate Names (SAN). These certificates were basically valid for any server name that was listed on the certificate. Most companies decided to add their internal domain name to their SAN certificates so they could go without worrying about the Autodiscover issues.
However, times change and now the major public Third Party Certificate Authorities (The people who sell SSL certificates) are refusing to issue SSL certificates that included .local and other common private TLDs. Why? Because a couple years ago ICANN announced that, for a nominal fee, companies or individuals could register any TLD they could think of for distribution to public DNS servers around the Internet. This meant that .local and .internal could potentially resolve on the public internet! And part of the Third Party CA chain of trust requires them to ensure that whoever purchases an SSL owns all the domain names used on their SSL certificates. This causes a huge problem with Autodiscover and similar features that rely on SSL certificates when used with Active Directory Domains using Private Domains. The private domain name could now *never* be added to the SSL certificate (until .local or whatever become publicly resolvable) and any attempt to connect to a .local server would generate a certificate error.
The New Best Practice
I call the current best practice new despite the fact that Microsoft has recommended it since 2007. I do that because it wasn’t necessary to use this best practice until the changes to SSL certificate creation policies. You could just add .local to the certificate and be done with it. You can’t any more. So we have to use a different best practice for managing our domain.
So, the new best practice is as follows, For your Active Directory Domain Name, use a subdomain of your public domain. What does that mean? Well, if your company has a public domain of company.com, set your Active Directory domain name to be something like internal.company.com or private.company.com. You can really use anything you want for the subdomain name as long as the primary domain matches a public domain name that you own (ownership is extremely important. Never pick a public domain name that you don’t own).
Why is this the Best Practice?
The answer here is relatively simple, it allows you to have a domain name in AD that can have SSL certificates generated by a public Certificate Authority, and you don’t have to manage a split DNZ zone. It’s basically the best of both domain naming strategies. There is, of course, a small drawback to this strategy, which is part of why it hasn’t been widely adopted yet (aside from lack of publicity). It means you have to type more when you are typing out FQDNs on your internal network. This is a miniscule issue, but one that seems to bother IT admins around the world. To those who this bothers, I would suggest using a short subdomain like ad.company.com, or even just a single letter, like i.company.com.
Avoiding Issues with Certificates in Exchange 2007+
For information, modern Active Directory Best Practices can help you avoid having trouble with certificate errors in Exchange. I wrote a blog on the best practice that can help you avoid Exchange Certificate issues here. If you follow that best practice when creating your AD environment, you won’t have to worry about certificate errors in Exchange. However, if you can’t build a new environment or aren’t already planning to migrate to a new AD environment in the near future, it isn’t worth the effort to do so when small configuration changes like the one above can fix certificate errors.