Windows Active Directory naming best practices?

Question

This is a Canonical Question about Active Directory domain naming.

After experimenting with Windows domains and domain controllers in a virtual environment, I've realized that having an active directory domain named identically to a DNS domain is bad idea (Meaning that having example.com as an Active Directory name is no good when we have the example.com domain name registered for use as our website).

This related question seems to support that conclusion, but I'm still not sure about what other rules there are around naming Active Directory domains.

Are there any best practices on what an Active Directory name should or shouldn't be?

Answer 1

This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.

I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.

So, if you own foo.com, use ad.foo.com or some such.

The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!

Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)

Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)

I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.

Answer 2

There are only two correct answers to this question.

1. An unused sub-domain of a domain that you use publicly. For example, if your public web presence is example.com your internal AD might be named something like ad.example.com or internal.example.com.

2. An unused second-level domain that you own and don't use anywhere else. For example, if your public web presence is example.com your AD might be named example.net as long as you have registered example.net and don't use it anywhere else!

These are your only two choices. If you do something else, you're leaving yourself open to a lot of pain and suffering.

---

But everyone uses .local!
Doesn't matter. You shouldn't. I've blogged about the use of .local and other made up TLDs like .lan and .corp. Under no circumstances should you ever do this.

It's not more secure. It's not "best practices" like some people claim. And it doesn't have any benefit over the two choices that I've proposed.

But I want to name it the same as my public website's URL so that my users are example\user instead of ad\user
This is a valid, but misguided concern. When you promote the first DC in a domain, you can set the NetBIOS name of the domain to whatever you want it to be. If you follow my advice and set up your domain to be ad.example.com, you can configure the domain's NetBIOS name to be example so that your users will log on as example\user.

In Active Directory Forests and Trusts, you can create additional UPN suffixes as well. There's nothing stopping you from creating and setting @example.com as the primary UPN suffix for all accounts in your domain. When you combine this with the previous NetBIOS recommendation, no end user will ever see that your domain's FQDN is ad.example.com. Everything that they see will be example\ or @example.com. The only people that will need to work with the FQDN are the systems admins that work with Active Directory.

Also, assume that you use a split-horizon DNS namespace, meaning that your AD name is the same as your public-facing website. Now, your users can't get to example.com internally unless you have them prefix www. in their browser or you run IIS on all of your domain controllers (this is bad). You also have to curate two non-identical DNS zones that share a disjoint namespace. It's really more hassle than it's worth. Now imagine that you have a partnership with another company and they also have a split-horizon DNS configuration with their AD and their external presence. You have a private fiber link between the two and you need to create a trust. Now, all of your traffic to any of their public sites has to traverse the private link instead of just going out over the Internet. It also creates all kinds of headaches for the network admins on both sides. Avoid this. Trust me.

But but but...
Seriously, there's no reason not to use one of the two things that I've suggested. Any other way has pitfalls. I'm not telling you to rush to change your domain name if it's functioning and in place, but if you're creating a new AD, do one of the two things that I've recommended above.

Answer 3

To assist MDMarra's answer:

You should NEVER use a single-label DNS name for your domain name either. This was/is available prior to Windows 2008 R2. Reasons/explanations can be found here: Deployment and operation of Active Directory domains that are configured by using single-label DNS names | Microsoft Support

Don't forget to NOT use reserved words (a table is included in the "Naming Conventions" link at the bottom of this post), such as SYSTEM or WORLD or RESTRICTED.

I also agree with Microsoft in that you should follow two additional rules (that aren't set in stone, but still):

1. You should NOT name your domain based on something that will change or become outdated. Examples include naming your domain after a product line, operating system, or anything else that is likely to change over time. Stick with something either geographical or concrete enough to make sense 5 or even 10 years down the road.
2. Stick with short names of 15 characters or less, this will allow for the NETBIOS name to easily be the same as the domain name.

Finally, I would recommend that you think long term as much as possible. Companies do go through mergers and acquisitions, even small companies. Also think in terms of getting outside help/consultation. Use domain names, AD structure, etc. that will be explainable to consultants or people here on SF without much effort.

Knowledge links:

http://technet.microsoft.com/en-us/library/cc731265%28v=ws.10%29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/en-us

Microsoft's current (W2k12) recommendation page for the root forest domain name

Answer 4

I disagree with using:

• example.com - for reasons already stated in other answers

I could accept using:

• ad.example.com - - for reasons already stated in other answers

But I wouldn't do it myself or recommend it. During company takeover, rebranding all hell breaks loose especially when management at that point wants things to change right away. Renaming migrations, changes are very hard or expensive.

Best way I would recommend is to buy domain that's irrelevant to company name and also irrelevant to company's brand. SIMPLE.CLOUD or similar should do just fine as long as you can own it.

I've seen big companies with 150k users using AD that's still referencing old company they bought years ago, or companies that changed names and even though it doesn't matter in the long run that you are using \login (if you can't use UPN) it's still looks bad in front of management who doesn't understand why it's not trivial to change it.

Answer 5

I always do mydomain.local.

local is not a valid TLD, so it never competes with an actual public DNS entry.

For example, I like being able to know that web1.mydomain.local will resolve to the internal IP of a web server, while web1.mydomain.com will resolve to the external IP.