AD Design 0: The Series

Active Directory (AD) is one of the more flexible products provided by Microsoft. While they have spreadsheets and white papers for how many users should be in each on-prem Exchange database or how you should structure your site collections in SCCM, guidance on AD design is kind of sparse. My assumption is because directory designs are so environment-specific as to be resistant to generic instructions. This flexibility means two things:

1. You can tailor the configuration and security of a domain to precisely and efficiently match the requirements of the environment it's there to support, making maintenance easy and allowing for future expansion.
    
2. You can screw things up really, really badly and not even know it.

You see, the assumption in AD overall is you know what you're doing. There are very few warnings, no popup to let you know you just granted Bob in Accounting the keys to the kingdom or an easy wizard that lets you review your configurations before deploying them to the enterprise. So, more than many other products, you need to think before you do anything in AD. If you're a Domain Admin and not just a little bit scared every time you open up Active Directory Users and Computers in a production environment, you've lost sight of how much power you have.

So without official vendor documentation, where is one to go? Unfortunately, because AD seems so simple, many users think they can jump in and make it up as they go. "Oh, a thing that says Computers," they say. "I'll put my computers there!" They're given default group policy objects (GPOs), so they make any needed changes in those policies. They're given default domain groups like Backup Operators and Account Operators, so they populate those groups with a limited understanding of what access is being ranted. And all those things are exactly the wrong ways to build a domain based on good things like the principle of least privilege and scalability.

Another reasonable course is to look at existing domains to see what others have done. I mean, they're functioning production domains, so they must be set up correctly, right? Unfortunately, there can be a huge difference between a functional domain and a properly configured one. The person who built it might have started with zero knowledge and been one of those "I'll just start making stuff!" people. Maybe it was built for an incredibly simplistic purpose, but you're being asked to expand it to accommodate a new service. Maybe it has switched hands a few times and has no cohesive design anymore. Just because it works doesn't mean it's correct.

The next step is to look outside the company/entity:

• Training sessions! In my experience, the amount of information that can be usefully transferred during a short-term, hands-on training session is not significant. Also, developing curriculum is difficult for the same reasons it is tough to make definitive white papers: each deployment is so unique. Getting the correct mix of practical and theory training can also be tricky. But the biggest hurdle of all is probably the cost: even remote sessions can cost several hundred dollars, and travel sessions can easily be thousands with expenses included.
   
• Books! Back when I started working in IT, having a collection of training volumes somewhere in one's office was a badge of honor. In my experience, the quality of IT books varies wildly, and unless they come with an accompanying PDF or eBook version, searching sucks. It's 2022; I'm not going to use a paper index. These are far cheaper than most training sessions, but it's still a cost, and the combination of signal:noise ratio and lack of two-way communication can affect their usefulness.
   
• Consultants! I'll say this up front: overall, I don't like how consultants normally operate. They're mercenaries, usually paid a flat-ish rate to accomplish a specific task. That means they have a built-in incentive to accomplish that task as quickly as possible, which sounds good, but is usually bad in IT. Proper documentation and training take time, but are not required in most contractor agreements. So they come in, do the work, and leave. If something breaks or there are future questions about what they did, they're only happy to charge you exorbitant hourly fees to tell you what they should have documented in the first place. Even if the task is training, they can rush through the content and technically achieve their task, though their students may not understand even the basic concepts. The worst case scenario is them leaving you with a "magic box" situation where you don't even know how your own system is configured, just that it works a certain way for now.
   
• Other! AKA, what you're reading. The internet is huge, and some really intelligent people are happy to share their useful knowledge as a service to others. There are tools that allow these people to share their ideas and experiences for free with anyone with the curiosity and motivation to find them.

I'm trying to be one of those useful people. I'm not making any money off this site (unless I've started doing AdWords or something since this writing), and I have no delusions of formally publishing anything. I was incredibly blessed to have a amazing mentors at my first job who taught me the concepts and theories that have shaped who I am as a sysadmin, mostly for the better. Since then, I've again and again encountered situations where the people responsible for very important IT systems were obviously unable to do so competently. I've also encountered people who were hungry for ways to further their career or avoid those major mistakes by learning the core concepts in my designs. This series is a way to try to address both.

I will present a mixture of specific prescriptive and general ideological guidance, and I'll try to make clear which is which. I don't claim to have the absolutely optimal solution to any problem, just ones that work efficiently (elegantly, if possible) and adhere to basic security principles. If you have a reason to use a different label or switch up the design a little: great! My primary goal is getting people to fully think through their designs, no necessarily become acolytes of mine.

Of course, this is all moot unless I know what I'm talking about. I invite you to judge based on how much sense I make, but it helps to have a rough idea of the author before jumping in, so here's a list of qualifications and caveats:

• I've been employed in a full-time enterprise IT position for 17 years, and I was a student worker for a little over 2 years before that. Active Directory has been my primary service for that entire time.
   
• I have never worked a Help Desk/primarily customer assistance role in IT. My old job that routinely required interaction with the public/end users was as a cashier/stock boy at PetsMart for three years in high school. I wish I could say I took some test or otherwise really impressed someone to get that enterprise student worker gig in college, but the truth is I just knew the coordinator of the department.
   
• My first full-time IT job was at the school where I was a student worker. A position opened up my junior year, and they thought enough of me to hire me out and pay for the rest of my degree.
   
• That first shop had three domains in a single forest and 25,000-30,000 users between students, faculty, and staff (depending on time of the semester). I was also one of the two admins tasked with upkeep of the on-prem Exchange system.
   
• We were a state university, so the systems and demands at that job were far less than what I would later experience. The lack of money or need for expansion meant I was mostly a steward as opposed to an architect.
   
• I have been in my current position for right at 14 years. It's a financial software/services company with 8,000 employees, offices across the US, and several major datacenters in addition to our public cloud presence.
   
• I don't currently hold any AD-specific (or even Windows-centric) certifications, just a few ITIL ones my company requires. I went through a season years back where I got several certs, and I all I really got was a handful of tricks. Getting those certs mostly involved simple regurgitation of example test questions and the "Microsoft certified" best ways to do something. I believe in learning by doing what matters to you and your job, not memorizing all the features of dozens of MMCs, most of which you'll never use.
   
• I have extensive experience in both building greenfield domains and retrofitting existing ones to align with the design and practices I'll cover here.

So there you go. I hope what I share here is useful enough to be passed around, if only so the domains of the next business my employer purchases are in better shape than the last few.

A note: this series is going to assume a familiarity with the basics of AD, for which there are copious resources online. If you don't know the differences between a group object and a user object, some of this may be over your head. If that's the case, I'd suggest doing some "Intro to Active Directory" reading before starting this series.