Active Directory: Active Directory structures
While simple is often best, you might want to consider applying a more creative layout to your Active Directory infrastructure.
Brien M. Posey
One thing has always surprised me when looking at real-world Active Directory deployments: Although there are certainly exceptions, in most cases, organizations stick with the simplest setup with which they can realistically get away.
In some ways, this shouldn’t be a surprise. It reminds me of a college professor who often said we should live life according to the principle of KISS—Keep It Simple, Stupid. Perhaps nowhere does this principle apply more accurately than the world of IT.
Any seasoned IT professional knows keeping things simple reduces the chances of experiencing problems. It also makes troubleshooting a lot easier when something does go wrong. While I’ll be the first to admit there’s something to be said for simplicity, when it comes to your Active Directory infrastructure, you might be better served by a more creative structure.
There’s absolutely nothing wrong with using a standard Active Directory topology. There’s a reason Microsoft made the standard topology the default. These slightly more detailed designs, however, might be more appropriate for larger organizations needing to segregate management responsibilities.
User domains
In most real-world Active Directory settings, the domain structure mimics the organization’s geographical structure. For example, if an organization has three offices, it’s likely to have three domains. That certainly isn’t to say that every organization uses this design, but it’s the most-common type of Active Directory structure. While geographic Active Directory topologies are common and indeed effective, you might also want to consider some alternative domain structures.
As you’re no doubt aware, Active Directory is really nothing more than an elaborate database. An Active Directory database is filled with various types of objects. Each object is assigned one or more attributes. Some organizations base their domain structure on specific types of Active Directory objects. One clear example of this type of classification is user domains.
A user domain is an Active Directory domain that has the sole purpose of managing user accounts. To give you an idea of why this is useful, consider one of the companies where I used to work. This particular organization had a few thousand users. There was always a high rate of employee turnover. Consequently, the organization employed two people whose job it was to create, provision and remove user accounts.
In this type of situation, a user domain proved useful. This type of domain structure gives the users tasked with account maintenance full administrative control over the user accounts. It does not, however, grant access to any other Active Directory objects or functions.
There are other ways to accomplish this type of administrative-duty isolation. Even so, a user domain structure might help an organization to stay better organized. If nothing else, it helps make the individual domains less cluttered. It also provides a sense of physical administrative isolation. Some organizations might prefer this to the logical administrative isolation that can occur when various object types reside in a common domain.
Resource domains
Resource domains are similar to user domains. These are single-purpose in nature and used to enhance security or make the Active Directory structure more logical or more manageable. There are real-world Active Directory deployments in which all desktop computers are grouped into a dedicated resource domain. There are also other resource domains used for other types of resources. For example, one organization placed all its servers running its primary line-of-business (LOB) application into a dedicated resource domain.
Resource domains are probably the most useful when they’re treated as management domains. For example, I created a dedicated Active Directory forest designed to act purely as a management domain for my Hyper-V servers. There are a couple of reasons why I chose to do this.
The first is a management reason. System Center Operations Manager 2012 (and a number of other management products) can only manage servers that are members of an Active Directory domain. I didn’t want to join my Hyper-V servers to my primary domain because all my domain controllers for my primary domain are virtualized. I didn’t want to risk not being able to log on to a Hyper-V server simply because the virtual DCs were offline. Joining the Hyper-V servers to a dedicated Active Directory management forest solved this problem.
The other reason I chose to create a dedicated resource domain for my Hyper-V servers has to do with some of the new features coming in Hyper-V version 3.0. One of the Hyper-V 3.0 features I’m most excited about is the ability to replicate a virtual machine (VM) from one host server to another.
This type of replication isn’t necessarily a failover clustering solution, but rather a disaster recovery solution that can help you maintain an up-to-date copy of your VMs on an alternate host server. If something were to happen to a disk array or primary Hyper-V host, there’s another copy of your VMs you can fall back on. In order to use this feature, however, both the host server and replica server must be authenticated.
The easiest way to provide this authentication is to join both servers to a common domain and use Kerberos. As such, creating a dedicated resource domain for Hyper-V servers makes perfect sense. This is especially true when you consider there are other Hyper-V features that also require domain membership.
Resource domains and user domains aren’t mutually exclusive, by the way. Some organizations use a combination of user domains and resource domains within a common Active Directory forest. Both have their strengths, and you can apply both as needed.
Geographic topology
The vast majority of Active Directory deployments in the real world are based on geographic structure. For instance, an organization with five branch offices might use five separate domains—one for each office that includes all the physical machines within that office. Technically, there’s nothing wrong with using this type of Active Directory topology—but there are a few things you should consider.
First, it’s important to not confuse domain structure with site structure. The Active Directory site structure should always mimic an organization’s geographic topology. For every wide area network (WAN) link there is between offices, there should be a corresponding site link within Active Directory. Also, the computers that are located within a physical office should be placed within a common Active Directory site. Ideally, each location should use a dedicated subnet, because you can’t have a single subnet span multiple Active Directory sites.
The reason the Active Directory site structure is so important is because the site structure has a direct impact on the volume of Active Directory replication traffic that can flow across the WAN links. For example, imagine an organization has multiple branch offices, but it chose to configure its Active Directory as a single domain. Again, there’s technically nothing wrong with that approach, but it can be inefficient.
In a situation like that, updates to the Active Directory could potentially be made to any writable DC anywhere within the organization. When an update occurs, it’s that DC’s responsibility to make the update available to the other DCs.
Because this organization didn’t make use of an appropriate site structure, a common update won’t be able to pass over a WAN link multiple times. For example, if there were five DCs in a branch office, then an Active Directory update could potentially be sent across the WAN link five separate times, once for each DC.
One DC in each Active Directory site acts as a bridgehead server. The bridgehead server’s job is to receive Active Directory updates from across the WAN link. Then it distributes those updates to the other DCs within the site. This means Active Directory updates would only need to be sent to each branch office once, regardless of how many DCs exist within that branch office.
What about organizations that use a separate domain for each branch office? If each branch office has a dedicated Active Directory forest, then you don’t need to worry about defining Active Directory sites. On the other hand, if each domain is a member of a common forest, then you should definitely implement an appropriate Active Directory site structure as a way of keeping forest-level Active Directory replication traffic in check.
There are many different ways to set up an Active Directory domain topology. Ultimately, you should choose the topology that makes the most sense for your organization’s physical layout and network infrastructure. This might be a single domain model, or a multi-domain model that’s based on geographic proximity, users or even resources.
.jpg "Brien M. Posey")
Brien Posey, MVP, is a freelance technical author with thousands of articles and dozens of books to his credit. You can visit Posey’s Web site at brienposey.com.