Private Namespaces In Active Directory

For purposes of this post, a private namespace refers to the DNS name of the forest root in Microsoft Active Directory. A private namespace is essentially any DNS name that is not registered; it can even be a registered name (assuming you never want to talk to the registrant's web site). Many of the customers I work with like the concept of private namespaces because they believe it provides them with security, since the name cannot be resolved outside the local DNS infrastructure. Incidentally, many of these customers have the same belief about private IP Address ranges. If they're not routable, or not resolvable, they can't be attacked.

Let's take a real world example. Can a burgler break into your house without a map? Probably, and most likely the burgler doesn't even know who you are; your house just happens to be in his proximity when he decides to commit his crime. Don't viruses, and more appropriately worms, behave the same way? Aren't they merely an attack of opportunity, choosing random addresses within their proximity.

I am not sure where the notion of security through namespace obfuscation came from, but many people are still convinced of the belief. I did some research into this and thought I would share what I know so that you can make sound technical decisions in your AD Designs and not be pursuaded via political pressures.

When Microsoft introduced Windows 2000, a large number of smaller customers were still not connected to the Internet and some uncertainty existed as to whether broadband for small business would be a reality in the timeframe that such customers might deploy Active Directory. Because AD is dependent on DNS, and a small company may not have a registered DNS name, the private namespace option was (well) documented as a work-around to illustrate the flexibility of Active Directory and allow these organizations to proceed with their deployments in advance of connecting to the Internet. 

Several folks read our training material from larger customers and came to the conclusion that if a private namespace was not resolvable, it was not reachable (which is true, if we're talking about the casual user - who generally isn't the threat we're defending against). Out of this collective interpretation, several folks jumped on the bandwagon of security through obfuscation and the concept took on a life of its own. Even some Microsoft engineers began to recommend this as a superior and more flexible option. 

In spite of their private namespace designs however, many of these same organizations quickly learned they were not any better protected from attack, as attacks were based generally on IP Address ranges, or transmitted over common channels like email and web browsers using the same old tricks (albeit more sophisticated) as the old DOS days when viruses rode around on floppies.

The fact is, the best design is a registered design. This doesn't mean that private namespaces won't work, don't work, or are unsupported. But they can present potential problems because, not being registered by an authority figure, the possibility of having two forests of the same name becomes a reality. If two organizations were ever to merge, it would be a painful experience given that forests of the same name cannot communicate with one another. It's like a time traveller's paradox causing both sides to fail in resolving the other. While this scenario is remote, it is possible and should be at least considered when planning your own namespaces. 

I had a couple of customers that ran into this. They were considering a single forest and a federated committee was formed to do the design. The design called for a private namespace, but it was later decided that, being separate branches of governement, they probably needed separate forests. However, when they agreed to separate, no one took responsibility for the name space. Ultimately, they each deployed their own forest with the same root domain name. It wasn't until they tried to talk to each other that they realized their mistake and then began the battle over who owned the name. In the end, it was decided that they just wouldn't talk. After all, they were separate branches of governement and should remain separate.

If you are going to use a private namespace, at least ensure that as part of your planning you establish an internal DNS registration process to protect the private names within your federation and ensure that ultimately, everyone can still talk if they one day require a trust relationship.