Wrong, wrong, wrong.

It can be hard to admit that. We’re naming the fully qualified domain name (FQDN) of an Active Directory domain either a valid name or using .local TLD and these are both incorrect. Recently, when I was again tasked to build a small (200-ish user) Active Directory domain from scratch, I was again confronted about how wrong those of us in this industry have been. What’s even worse is that Microsoft has been recommending the “Right” way for 14 years!

Note: A little context is important here. I’m talking about small, single-domain installations. This is not related to larger, multi-domain forests that may have large complexities not covered here.

And, we’re all still teaching each other this crap. Simple Active Directory domains have been the core of system administrators’ experience with Windows since it was possible in the early aughts. For those of us that came from a Windows NT 4 flat domain structure, the complexity of a directory seemed daunting. We took shortcuts.

As someone who has an MCSE in Windows NT 4.0 and flat domain names, coming into Active Directory was not the easiest transition for me. In fact, at the time Microsoft’s new directory service started to take hold, I had more experience with Novell’s NDS directory service. As history unfolded and Windows took a massive amount of the server market share, I would deploy countless Active Directory setups along the way. Many of them, followed these practices.  This is all underscored by the fact that Microsoft themselves offered best practices for this in the era of Windows 2000!

In Fact, I recently used the Windows Server 2012 Essentials “Experience” setup wizard and after answering a number of basic questions that did not include the fully qualified domain name, I was left with a “.local” domain. How can this be, I wondered.

Even crazier, the Internet is awash with references that are blatantly wrong. In my search for a Youtube video showing a domain setup, I couldn’t even find one that named the domain even remotely like best practices indicate. Not even one. Seriously, here are some examples of tutorials and domain names they use while running dcpromo:

Please, don’t listen to these guys.

Don’t use .local 1.

If you use .local (and let’s say the server is named DATA), the fully qualified server name in the domain might be called data.cwl.local.  The trouble here is that .local isn’t a valid TLD and it never will be. You can’t run certificates on domains like this 2. It won’t work with some Apple services. So, when the day comes that you want to expose this server externally you can’t, and you’ll have to have one name internally and one externally.

Don’t use you’re raw Internet domain 3.

Using a valid base domain (like cwl.cc) goes a different way. You’ll end up with a server name that might look like data.cwl.cc. This is valid internally and uses a good basic name, but you’ll run into issues here because you want to leave all the base hostnames free for DNS use.

Here’s how you should do this. Create a DNS domain between your server’s name and the company’s domain name. The way to do this is taking data.cwl.cc and making it data.ad.cwl.cc. The “ad” can be anything you want. Then, externally, you can create this hostname in your public DNS (if you wanted), and run public services.

How is this done on your public DNS? It’s actually amazingly straightforward. In your DNS configuration just create an A record that starts with data.ad like this:

This is a case where designing it well provides later options (if you want them). If you never want to create your data.ad.cwl.cc externally, then you never have to. This has no security implications whatsoever. You might also just be making the next administrator’s life easier.

If you’re ready to create clean AD domains, you should subscribe to my newsletter