In this episode our intrepid scrub explains his Active Directory structure and drops a script to set up your own.

I set myself up a test domain on Azure, mostly to see how it all works up there, and how many ways I can break it.  For this, I needed to set up a domain, multiple times.  I wanted to use a bunch of my existing modules to (mis)manage these ADs, so I put together a couple of scripts to build a structural replica of my work domain.  The domain you get at the end of this is pretty good if I do say so myself.  The security won’t be set up at all, but that can be added to the script fairly easily later, and would be good practice in the meantime.

One day when I was considering posting some of my work, I thought how hard it would be to explain why bits of it were doing things in a certain way.  Without an example domain to point to, some of this would make very little sense.  This test domain I set up is the perfect solution.  It will create (or at least explain) the OU structure that I work within, saving a lot of time in the long run.  I don’t want to explain each subsystem each time I post a script any more than you want to reread it.

I’m going to assume you are sitting in front of a VM Management console of some sort (Hyper-V/Azure/VMWare.etc.) with at least a couple of servers ready to go.

To start, we’ll need a Windows 2016 (GUI version) server to be our domain controller.  Give it a secondary disk.  We will assign this to Z: and use it for NTDS and SYSVOL.  Once it’s up, log in and crank open an admin PowerShell console.  Throw this in:

Import-Module ADDSDeployment
Install-ADDSForest `
 -CreateDnsDelegation:$false `
 -DatabasePath "Z:\NTDS" `
 -DomainMode "WinThreshold" `
 -DomainName "PSAD.local" `
 -DomainNetbiosName "PSAD" `
 -ForestMode "WinThreshold" `
 -InstallDns:$true `
 -LogPath "Z:\NTDS" `
 -NoRebootOnCompletion:$false `
 -SysvolPath "Z:\SYSVOL" `
 -Force:$true

And then do as you’re told for a while, and eventually, you’ll have a domain controller and a boxfresh Active Directory.

The next step is to put your OU structure in place.

On your new DC, open an admin PowerShell window and cram this in: (Remember to change the PSAD to match your new domain name)

# This will create the admin OUs, This would generally be off limits to all but Domain Admins 
New-ADOrganizationalUnit Admin
# Actual Domain Admin accounts
New-ADOrganizationalUnit -Name Users -Path "OU=Admin,DC=PSAD,DC=local"
# High-Level Service Accounts
New-ADOrganizationalUnit -Name Service -Path "OU=Admin,DC=PSAD,DC=local"
# High-Privilege Groups
New-ADOrganizationalUnit -Name Groups -Path "OU=Admin,DC=PSAD,DC=local"

# Create the various client-end OUs, for users, computers, groups and such. 
New-ADOrganizationalUnit Organisation
# All non admin/service accounts will be under here somewhere
New-ADOrganizationalUnit -Name Users -Path "OU=Organisation,DC=PSAD,DC=local" 
# This is the actual userbase
New-ADOrganizationalUnit -Name People -Path "OU=Users,OU=Organisation,DC=PSAD,DC=local" 
# Sub OU for IT staff and their crazy ways
New-ADOrganizationalUnit -Name IT -Path "OU=People,OU=Users,OU=Organisation,DC=PSAD,DC=local" 
# OU for disabled accounts - blocks login
New-ADOrganizationalUnit -Name Disabled -Path "OU=Users,OU=Organisation,DC=PSAD,DC=local" 
# This is for generic accounts, which we can't seem to get around having
New-ADOrganizationalUnit -Name Shared -Path "OU=Users,OU=Organisation,DC=PSAD,DC=local" 
# All client-facing computers should be in here somewhere
New-ADOrganizationalUnit -Name Computers -Path "OU=Organisation,DC=PSAD,DC=local"
# Desktops/static devices
New-ADOrganizationalUnit -Name Desktops -Path "OU=Computers,OU=Organisation,DC=PSAD,DC=local" 
# Laptops/Mobile devices
New-ADOrganizationalUnit -Name Laptops -Path "OU=Computers,OU=Organisation,DC=PSAD,DC=local" 
# All the groups that we are allowed to put users in
New-ADOrganizationalUnit -Name Groups -Path "OU=Organisation,DC=PSAD,DC=local" 
# All users should go in a role group, and only a role group...
New-ADOrganizationalUnit -Name Roles -Path "OU=Groups,OU=Organisation,DC=PSAD,DC=local"
# Unless we have a badly written software package, in which case, they need to go straight into a resource group.
New-ADOrganizationalUnit -Name ResAcc -Path "OU=Groups,OU=Organisation,DC=PSAD,DC=local"

# Create the resource OUs, this will be where we put our infrastructure, services and general backend stuff
# We will just create a single resource group, Domain Services, for non-DA admin accounts. 
New-ADOrganizationalUnit Resource 
# Applications holds all the services we provide.  Sub-OUs will be named after the package or 
# service (ie/ Oracle/Sage/CustomDB)
New-ADOrganizationalUnit -Name "Applications" -Path "OU=Resource,DC=PSAD,DC=local"
# Then we have all the infrastructure components.  This will include OUs 
# like: Security/System Centre/Virtualisation/Exchange/Backups. All Resource OUs have the same structure.
# The first one is Domain Services.  Others are created by script.
# All the Admin accounts and tools should be in here.  This includes things like jump boxes.
New-ADOrganizationalUnit -Name "Domain Services" -Path "OU=Resource,DC=PSAD,DC=local"
# All the directly realted computers go in here
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# This is for servers including cluster nodes.  Admin workstations can go in here too in some cases
New-ADOrganizationalUnit -Name "Servers" -Path "OU=Computers,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# This is just for virtual cluster names
New-ADOrganizationalUnit -Name "Shared" -Path "OU=Computers,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# All the related groups go in here
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# Role groups are for user accounts and are nested in...
New-ADOrganizationalUnit -Name "Roles" -Path "OU=Groups,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# Resource Access groups.  These are granted access to resources.  They only contain other groups.
New-ADOrganizationalUnit -Name "ResAcc" -Path "OU=Groups,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# User accounts go here
New-ADOrganizationalUnit -Name "Users" -Path "OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# People meaning actual people.  This is not often used
New-ADOrganizationalUnit -Name "People" -Path "OU=Users,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 
# This will be service accounts and generic accounts (ie. supplier support accounts)
New-ADOrganizationalUnit -Name "Shared" -Path "OU=Users,OU=Domain Services,OU=Resource,DC=PSAD,DC=local" 

So if we ignore the out-of the-box AD structure, we are left with only three top level OUs.  And they are broken down like this:

The Admin OU is just for DA accounts, groups that grant high privileges (schema/domain/enterprise admins) and high-level service accounts.  This OU would be locked down tight in a production environment, but we don’t care about that for this test environment, so it’s wide open.

The Organisation OU is basically everything outside the datacentre.  Users, workstations, contacts, distribution groups, global groups for access to things.  That sort of thing.  There is an OU under ‘People’ called ‘IT’.  This is for IT staff on their regular accounts, as they often break all the rules all the time need some slight alterations for their workstations, but still benefit from having the ‘end user’ experience in their day-to-day work.

The Resource OU is everything inside the datacentre.  Servers, hypervisor farms, networking equipment, Exchange, file services, AV.  It can go on forever and often will, as I find daily at the office.

Having this three way split is a very simple and effective way to do delegation.  Domain Admins control all three OUs, infrastructure admins control Organisation and Resource, desktop support control Organisation and service desk get limited rights to Organisation only.  This allows desktop engineers to add a new workstation to the domain and move it from the base Computers OU to the Organsation\Computers\Desktops OU.

At some time in the future, I will post some or all of my AD module, as it is designed to work with this exact structure.  With the module, almost everything with a name gets set up automatically and everything is logged.  And because I wrote the policy and wrote the scripts to match, everything matches policy, every single time.  Having worked with a number of Domains/ADs before, the maintenance overhead on this is refreshingly small, and should stay that way.