AD Design 1: The Case for a Functional Root

This is part of my ongoing AD Design series. Check here for primer on the intent.

As mentioned in my last post, I'm going to assume a certain level of knowledge about Active Directory is held by the readers of this series. One of those assumptions is you can navigate the wizards necessary to promote a couple domain controllers and get a base domain up and running. Again, if that's outside of your abilities, there are many, many guides for that online. For this post, I'm going to assume you're starting with a brand new domain.

It may seem elementary, but two of the most important things to consider in AD design are:

1. How your configurations will affect existing systems within the domain. 
2. How your configurations will affect future efforts within the environment.

How long you've been managing domains and your knowledge of how your systems integrate with your domain will determine how well you're able to guess at those (and make no mistake, you are guessing). What I'm suggesting in this post will affect both of those and serve as the basis for my directory design going forward.

In short, I believe each domain should have an OU under which all non-default resources should be housed. My previously-mentioned coworker coined the term "pseudo root," but after a few years of minor confusion, I've switched to "functional root." I normally name it the NetBIOS label of the domain for easy identification.

Using a functional root accomplishes several things:

It segregates default resources.

To clarify, when I say default resources, I'm talking about all the stuff you see in Active Directory Users and Computers right now in your brand new domain. This includes many resources that are either of a highly-sensitive nature (Domain Admins group, default Administrator user, etc.) or vestiges of previous functionality that is considered non-secure now (Guest user, Windows Authorization Access Group group) or both (Account Operators). To my mind, it is good design to cordon these off so it would be very difficult for someone to accidentally grant elevated rights over them.

Enter the functional root. If you create a root level OU under which you create all servers, workstations, user accounts, service accounts, groups, and all other resources, all the default resources on the root can functionally be managed separately. If you set up your permissions correctly, they will be outside the scope of anyone but the users who have complete control over the domain.

It segregates domain controllers.

Say your'e designing a very simple, small domain. You'd be tempted to use the default Computers container to house all your member server/workstation objects. I don't think that's a good idea, but a lot of people do it. In that scenario, you'd have to apply all custom group policy settings to the true domain root (you can't link GPOs to containers), which would also affect domain controllers.

This isn't a big deal for most settings in the standard Microsoft group policy schema, but what about controls over third-party applications like Adobe Reader or Microsoft Office? Do you really want ADM/ADMX templates writing third party application registry settings to your domain controllers? I don't.

If you're still not swayed, here's the best reason: you should probably be using group policy to manage both widespread and specific local group membership, and domain controllers don't have local groups. If you have to apply the widespread permissions at the domain root, you'll likely also grant those users elevated rights in the domain, up to the Administrators group. This is very bad.

It allows you to show the separation of resources to auditors.

If you're an auditor reading this, first of all: God bless you. Even if you've only read the first part of this post, you now have more Active Directory knowledge than the average audit facilitator I've encountered.

Second, I'm sorry for that shot and the many others that I'll be taking at auditors in this series. But the wide-open configuration possibilities for AD I've mentioned earlier mean it usually can't be distilled into binary "good and bad" settings or even definitive best practices for things like group policy. I've yet to meet an auditor that can even understand the basics of the reports I return to them or (and this is the important part) one that has any interest at all in learning about the technology. As a result, I spend a lot of time building these concepts from the ground up time and time again to explain our configurations in various domains to them. It's depressing/disconcerting that those tasked with making sure I'm doing my job in a secure way have almost zero knowledge of the technologies involved.

Anyway...

When you do an export/report of your domain resources for auditors or your boss or whoever, you're going to get asked about the big stuff like Domain Admins other default resources. It really cuts down on explanation time if you can just say "Anything outside of this OU can only be modified by Domain Admins/Administrators/Enterprise Admins."

It allows support personnel to identify resources they don't need to manage.

If you simply create separate OUs on the root of the domain, groups like Remote Desktop Users or Server Operators can easily be misidentified by support personnel as something they need to manage since it's at the same level as other containers that house resources they modify.

If you have a functional root, you can tell all support personnel the same thing you tell auditors: if it's outside the functional root, only domain administrators should be touching it.

If you really screw up, you can revert to a default configuration.

I hope this only really applies to test environments, but if you screw up permissions or group policy badly enough that you don't know what to do to get back to a working state, you do have something just below a nuclear option (rebuilding the domain), and that's to create a new functional root and start again. Only security and group policy from the true root will be present in that new functional root, and if you've followed best practices, those are more likely to be clean than lower-level configurations. If this is a production environment, updating your resume might not be a bad idea, either.

Let's go back to the beginning of the post and answer the two big questions:

How will this affect existing systems?

New Domain
If you're starting from scratch, your DCs are your only systems right now, so this will have no effect on them.

Existing Domain
If you're implementing this model into an existing domain, any resources moved into the functional root could be affected, especially if they're location-dependent (distinguishedName is checked/stored). I'll cover that more in a later post.

How will this affect future systems?

All future systems and their resources will be created under this functional root. This includes computer, user, OU, contact and group objects, as well as any of the weird ones like groupOfNames that vendors will ask you to create for some reason.