Microsoft’s Best Intentions Have Led to Some Unintended Consequences

The Challenges of Managing a Multi-forest or Multi-domain Active Directory (AD) Infrastructure
 
How Did We Get to This Point?
This issue dates back over fifteen years to Windows 2000, when Microsoft recommended that companies organize their network into multiple forests for security reasons. In the Active Directory world, we have a series of domains that are meant to work together, called forests. Even when a single forest made sense, Microsoft architectural guidance suggested that in valid scenarios you should separate that forest into multiple domains. Beyond that, and typically for larger companies, Microsoft recommended that you would create multiple forests that, by design, don’t necessarily link with, or ‘trust,’ each other. Your domains and forests may have been organized by department, geography, or some other way.  At first, this structure—multiple domains per company, multiple forests, and no trust between forests—wasn’t much of an issue.

And just so we’re all on the same page, AD (or Active Directory) is Microsoft’s security and authorization platform for issuing credentials and verifying if those credentials are accurate—it’s the entire structure that we’re talking about.

As time went on and as you merged or acquired another company and followed Microsoft’s suggestion that you create a separate environment for that entity, there was no pressure to merge the domains so people just left things in place because Microsoft promoted it that way. There was one administrator per domain, and this policy of ‘segregation’—which started as a security measure—continued.
 
What’s Wrong with All of That?

  1. Administrative Overhead: When you have separate security structures, no one person has the administrative rights to every environment. For instance, when you have to make a change in one environment, that change has to be made in five or perhaps ten locations, and there’s no way to automate the process. Furthermore, management of multiple domains, forests, etc. becomes more difficult. To deal with this, companies created massive policy and procedure manuals – all because of this segregation. And Microsoft’s core architecture promoted this structure, so it seemed like the right model to follow
  2. Architectural Complexity: From an architectural standpoint, key services such as your DNS are OK if you’re in the same domain. However, when you have multiple domains in multiple forests, then you need to find the right guy, as well as the right system, in order to implement the configuration and make any change. Just like the Yellow Pages or directory assistance, DNS helps you find what system is doing what job. When you make an inquiry, DNS returns a list of the names of those computers doing that job, and then gives you the IP address of where to find that computer.
  3. Difficulty in Supporting End Users: End user support becomes more difficult because most individuals have multiple names to look up. Any single person likely has multiple accounts with different naming structures. I could be garysteere@binarytree.com, gsteere@n2m.com, and Binary\steereg—all as a part of Binary Tree. Alone, this is just annoying; however, when you’re working with file server access and not just emails, it’s an entirely different ball game.
  4. Vulnerability to Security Attacks: Security policy is the real problem because one domain may be easier to break into than others—especially at those access points used less frequently. Furthermore, those infrequent access points are usually the ones with more sensitive information. Think I’m just trying to scare you? Not so. Here’s one of too many examples.

One company had a separate domain in place that was meant for testing – it was just a test environment. In theory, this financial services firm would test their new configurations first, and then apply them to the main production environment. Because this occurred in a test environment, it wasn’t bound by the same security and didn’t need to be audited. Then, someone broke into that test environment first and compromised the rest of the system, as well as the entire AD structure. All of the security identifiers had been compromised, and the company had to migrate everything away from the hacked environment. Needless to say, this unfortunate oversight cost millions and millions of dollars. And all because they had a connected domain, called test, which was not subject to the same security scrutiny. This company’s policies were good for their main environment, but not for the test environment. SCARY!

With caution in mind, stay tuned for my next two blog posts, where I’ll cover the fact that Microsoft no longer recommends separate forests as the norm AND the reasons that many companies are still using this outdated model. No worries, I’ll also cover the path forward and how Binary Tree can help.