Technology, Windows

Active Directory Structure and Config

I’ve learned a few things over the years, one them being that you need to organize Active Directory in an intuitive manner.  Once you decide on a structure, stick to it, otherwise you’ll end up with a huge jumbled mess on your hands.  In this post I’m going to discuss how I setup my OUs/Users, as well as some configuration changes that I’ve made to the environment.

I like the current structure that I’m using at work, so decided to employ something similar for my home environment.  First things first, I created my base OU and named it SKY.  Underneath that I created Accounts, Devices, and Groups.  From there I broke it down further.  Under accounts I have Administrator, Service, and Standard.  These do exactly what you would think… Administrator holds admin accounts, Service has service accounts, and Standard is plain user accounts.  Under devices I have Server, Tablets and Workstations.  With server being further broken down by Linux and Windows, whereas Workstations is broken down by Desktop and Laptop and then Windows/Linux respectively.  This allows me to target GPOs at the various OUs, while excluding Linux machines, and giving very granular control over which machines/servers are targeted.  The final OU, Groups, just holds security groups for the domain.  In a production environment I could see breaking this one down further to get some more granularity, but for what I’m doing I think just putting all the security groups in there will be fine.

AD OU Structure

I find this structure lends itself well to duplication, I.e. if you have multiple regions/offices/cities/etc, however you would want to split it out.  Just copy the structure with new names for the base OU and you have a common structure to apply group policy to, while still being able to customize each one as needed.

The first configuration change I made was to redirect the default Computer and User locations to my newly created OUs.  I opted to set SKY > Devices > Workstations as the default computer OU so that I could apply a bare set of GPOs to that OU that would apply to any newly created object.  I then redirected users to SKY > Accounts > Standard as I shouldn’t be automatically creating any service accounts, and don’t plan on adding any more admin users.  To accomplish this, just issue the following commands from an Administrative command prompt:

Up next, I enabled the AD recycle bin.  Maybe not today, maybe not tomorrow, but soon… and for the rest of your sysadmin life:  Someone, somewhere, will somehow delete something… either by accident, negligence, or malice… and when they do, the AD recycle bin will be there to save the day. To enable it, the forest functional level must be at minimum 2008 R2, and the account you use must be a Schema admin, and you must run it on the Schema Master server.  You can either go to Start > Administrative Tools > Active Directory Module for Windows Powershell and right click, run as administrator.  Open up a PowerShell prompt as administrator directly and then run command:

Or, provided you are on PowerShell version 3 or higher (which you should be on Server 2012 R2+) you can just type in the following command and it will autoload the module for you:

You will get a message alerting you to the fact that this is a permanent change (because you’re adding to the Schema) and cannot be reverted like this:

Enable AD Recycle Bin

To actually use the Recycle Bin to restore something, just open up Active Directory Administrative Center and find the Deleted Objects container.

Deleted Objects Container

Right click on an object, and select Restore/Restore To:

Restore AD Object

Clicking restore will place it directly back into the Container/OU it was deleted from, Restore To will allow you to choose the restore location:

Restore To

Lastly, the built in Administrator account needs to be locked down.  This account is dangerous for a variety of reasons… the top two being that it cannot be locked out (vulnerable to brute force attack) and simply renaming it isn’t enough because the SID always ends in 500 so attackers can still find it.  This account is a member of Domain, Enterprise,Schema and Administrator groups by default… it is the literal key to your kingdom, so you don’t want that floating around just waiting to be exploited.

Before you make any changes, create new accounts that have these privileges.  You don’t want to accidentally remove your own access.  Once that has been done, you can follow the steps below to secure the Administrator account.  What I’m going to describe here assumes that you have physical access to at least one of your domain controllers (Or in my case, console access to the virtual machine via the Proxmox hypervisor).  In the event of needing it for disaster recovery, the Administrator account could be enabled, the smart card requirement turned off, and then used to logon locally to a DC.  Access over the network will be disabled.

Open up Active Directory Users & Computers and navigate to YourDomain > Users > Administrator and right click, open properties.  Click on the Account tab and under Account Options check off Account is disabled, Smart card is required for interactive logon, and Account is sensitive and cannot be delegated.

AD Administrator Account

Next, create a GPO that can be linked to any OUs which contain computers.  Avoid linking this at the domain level, as it could render the Administrator account unusable even in a disaster recovery scenario.  In your new policy, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.  Here you will want to locate Deny access to this computer from the network, Deny log on as a batch job, Deny log on as a service, and Deny log on through Remote Desktop Services.  Edit each one, check the “Define these policy settings” box, and then click the Add User or Group button.  Click browse, and then type Administrator into the search box and click the Check Names button.  Here make sure you are selecting the built in account for Administrator located in the YourDomain/Users container.

Group Policy

In my case I needed to link this policy to the Domain Controllers container, and then to my newly created SKY > Devices OU so it would apply to the Servers/Workstations/Tablets OUs underneath it via inheritance.



Series Navigation<< DNS, DHCP, and RedundancyFile server replication with Robocopy >>

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.