When implementing (or more like “inheriting”) an Active Directory environment, it’s usually fairly straight-forward to figure out the physical layout. Physical layout defines how the network is laid out, the sites at the physical locations, the subnets associated with those sites and how the sites are connected. Dirk Popelka has written a really good blog posting about some of the downfalls associated with sites and gives a brief overview of all those components, if you are in need of a quick refresher click here. Once the physical design is figured out, the hard stuff comes into play and that is the logical design.
The logical design is more than how Active Directory looks when Active Directory Users and Computers is opened, it is also how many domains and forests and how are my OU’s going to be. Each decision will impact the next as well as day to day operations, security and group policies. Some items, with a little planning, can be easily modified. Others however will be harder and require much more planning and coordination.
I will break this down into various components. While some of it will be best practices from Microsoft, some will be from experience and lessons learned. If you have your own experiences around this subject that you’d like to share please post a comment.
In nature (as in “the outdoors”) a forest is a whole bunch of trees in an area, while in Active Directory a forest is a complete Active Directory environment. An Active Directory forest could have many trees or could only be one tree. That’s an odd concept and doesn’t relate back to nature well. If I referred to the one tree in my front yard as a forest, my neighbors would begin to think I was nuts.
By default, information stored in Active Directory is only shared within the boundaries of the forest; this makes the forest a security boundary for the information. The first domain becomes the forest root domain and the name of that domain becomes the name of the forest.
Domains: Going back to the nature analogy, a domain is a branch on the tree in the forest. In AD, domains are administrative boundaries that share a common directory database. They also share common security policies and trusts with other domains. Domains can be located all in one physical location or spread out amongst one or many different sites covering several buildings, a city, a country or continent(s). Domains are container objects that can hold millions of objects (Users, Computers, group policies, etc).
This is a good point in time to discuss namespaces, dns and domain trees. Domain trees are the dns name for a domain, take matrix.local for example. Adding a child domain called lab.matrix.local to the matrix.local will add a branch to the domain tree. More importantly this is called a congruent namespace because it creates a hierarchical DNS structure across domains. If we took this one step further and created a southwest.lab.Matrix.local domain it becomes more apparent of the hierarchy. If we add a couple more domains to our forest called Morpheus.local, Neo.local, and Trinity.local , we have just added 3 domain trees.
Below is a diagram of the above scenario:
Each color represents a domain tree and all of these domains are in the same forest. Being in the same forest there are some shared information amongst all domains, these include the schema and the configuration partitions.
Organizational Units: OU’s are the container objects that most administrators are most comfortable with. OU’s are used to break objects such as Users, computers, groups and servers into an administrative hierarchy.
Admins create an OU hierarchy that allows them to locate and manage objects easier. There are a couple general methodologies administrators use to arrange OU’s:
- By department: Each department shares certain common security and group policy requirements, so each depart is given an OU. For example: Accounting, Human Resources, etc.
- By location: Each location is given an OU to hold its resources from a given location
- By department, By location: Each department is given a top level OU, and then broken down by location
- By location, by department: Each location is given a top level OU, and then broken down by departments in that location
There is not just one way to do the OU hierarchy, it is more of what makes sense administratively for your organization.
How many forests do I need, or how many should I have? This is a difficult question to answer, but let’s tackle this logically J Is this a small IT shop or a global company. Remember the forest is the security boundary so if security and segregation of resources is the idea then perhaps multi-forest is the way to go. Some common reasons for additional forests is below:
- IT administrator inherits a forest when one company acquires another company that already had an established Active Directory. There may or may not be a cross forest migration in the future.
- Resource forests are another reason for additional forest. These come about usually when the Exchange admin wants to control Active Directory, or they want to not have to rely on the AD administrator to do certain things. Or the resources could be a shared resource amongst a couple companies and in a SaaS (Software as a Service) or a cloud service.
- One other very common reason is for critical assets and regulatory reasons. Companies will separate the resources that fall under the enhanced security regulations into a secured forest and keep the day to day business resources in the corporate forests.
I have a small company, that have several independent locations, how many domains do I need? This one can get interesting, first question I would have to ask is how many IT administrators are at each location. If you are a one-stop IT shop then it makes no sense to stand up different domains. Remember, domains are an administrative boundary. I had one IT admin tell me he had a separate domain in each location just in case the WAN link went down; the assumption was that users would still be able to log in. While that is correct, having a global catalog at each site would accomplish the same thing. Sometimes understanding the physical layout and network connectivity will help in these decisions. Creating multiple domains does not take away from managing Active Directory replication – The key thing to remember is that Schema and Configuration partition is still replicated across the entire forest, and with multiple domains each with the global catalog (partial attribute set of every item in the forest) would actually increase the amount of replication traffic.
Regional admins with different laws would be a great reason to create multiple domains. Having a domain in the US, Europe, and Asia would be a perfect example, this allows the regional IT admins to manage their own domains, users, computers, and group policy.
How should DNS be setup in a multi-domain environment? This too can have multiple right answers. By default the _msdcs.domain.com zone is replicated forest-wide (every DC that is a dns server in the forest). The other forward lookup zones, by default, will be replicated domain wide (every DC that is a dns server in the domain). The other domain dns servers will need conditional forwarders to the other domains at a minimum. This is necessary for domain controllers to find the A records of the other DC’s outside of their domain. Clients can also make use of these to find application or file servers located in other domains. Depending on the connectivity between domains, it may not be feasible to set the scope for a forward lookup zone to forest wide. In fact, I wouldn’t recommend that on an unreliable or on expensive metered connection. Utilizing stub zones is also a valid way to locate DNS servers from other domains without manual intervention. Again knowing the network topology and layout will help answer those questions.
In conclusion, Active Directory is very flexible in fitting into exactly what your company needs from it. No one person will be able to tell you that your Active Directory design will still be perfect 10 years from now. It is impossible to know what the future will hold by means of market changes or acquisitions. The key is to design for what is expected to happen and gradually change over time as changes in your business happens. Some bad design decisions will be harder to correct later, so plan, plan, and then plan ahead of time will help you make the best design descision.