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.