This blog is a work in progress but I will be keeping track of things to check when taking over an Active Directory Domain. This is not an all inclusive list but a list of common things to check.
ms-DS-MachineAccountQuota
By default in Active Directory this value is set to “10” which allows ANY user in Active Directory to bind ten machines to the domain. In the beginning stages of Active Directory maybe there was a need for this but now its just a big security risk.
Recommendation: Set this to zero
Protected Users Group
Look at highly privileged accounts and add them to the Protected Users Group if they are compatible with the protections that this group provides.
Recommendation: Add any real user accounts that are at Domain Admin or higher. (Enterprise Admins, Schema Admins, etc.)
krbtgt Account Password
Check the last time this password was changed and if it wasn’t changed in the last 180 days, change it.
Recommendation: Make sure you setup a schedule to recycle this password twice a year. This account holds two passwords so when you change the password you should change it twice, ideally 24 hours apart. That is a total of four password changes a year.
Verify SSL Certificates Exist on the Domain Controllers
Verify that valid certificates are in place for LDAPS calls over port 636. As part of this process investigate and try to remove any traffic that is talking on LDAP port 389.
Recommendation: Use either an internal PKI or public facing certificates to make sure all ldaps traffic is talking Active Directory over a secure connection.
Check if Exchange ExtensionAttributes were installed
If “ExtensionAttribute1” -> “ExtensionAttribute15” are in the schema of User/Computer/Group objects, check to see if any of them are in use.
Recommendation: If they are try to document what they are being used for and which ones are free and able to be used.
Check the Default Computer/User Bind OU
The default container for computer objects is (CN=Computers,DC=DOMAIN,DC=COM). This container cannot have group policy applied to it and objects should be set to write to another OU that can be better managed.
Excerpt from Microsoft here: Redirect users and computers containers – Windows Server | Microsoft Learn
“In a default installation of an Active Directory domain, user, computer, and group accounts are put in CN=objectclass containers instead of a more desirable OU class container. Similarly, the accounts that were created by using earlier-version APIs are put in the CN=Users and CN=computers containers.”
“Some applications require specific security principals to be located in default containers like CN=Users or CN=Computers. Verify that your applications have such dependencies before you move them out of the CN=users and CN=computes containers.”
Recommendation: If these items can be re-directed, redirect them to a different OU and make sure proper OU security is set.
Check Tombstone Lifetime / AD Recycle Bin
If the Active Directory Recycle Bin is not enabled, enable it!
The following PowerShell code can be used to see what the current Tombstone Lifetime is:
Write-Output “Get Tombstone Setting `r”
Import-Module ActiveDirectory
$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext
$DirectoryServicesConfigPartition = Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext” -Partition $ADForestconfigurationNamingContext -Properties *
$TombstoneLifetime = $DirectoryServicesConfigPartition.tombstoneLifetime
Write-Output “Active Directory’s Tombstone Lifetime is set to $TombstoneLifetime days `r “
Note that no value returned means the tombstone lifetime setting is set to 60 days (default for AD forests installed with Windows 2003 or older).
Recommendation: If it is not set to 180 days, set it to 180 days. If the AD recycle bin is not enabled, enable it!
Check to see if Sysmon is installed on the Domain Controllers
Recommendation: If Sysmon is not installed, work on getting it installed and configured on the Domain Controllers at a bare minimum
Check Domain Controller Firewall Settings
This may require a conversation with your Information Security team to understand how the Firewalls are configured that sit in front of the Domain Controllers. You want to make sure the bare minimum number of ports are enabled for client traffic and that admin ports are only able to be accessed by admins.
Recommendation: Review security with Information Security Team, and enable the Windows Firewall on all Domain Controllers and manage it with Group Policy. This also acts as an East/West traffic block so if someone gets into one server on the prod network they don’t automatically have RDP access per say to another DC on the same network segment. Setup monitoring for any RDP sessions, successful ones, and failures (including firewall logs). This will verify anyone RDP’ing to the DCs is legit, and will also help track down threat actors on the network. One of the first things threat actors will try to do is see if they have RDP access to the Domain Controllers, this is good information to send to the SOC or InfoSec.
Check to see if RPC Ports are restricted
Recommendation: If RPC Ports have not been limited on the Domain Controllers, limit them to a few ports, say 100, or 1,000, and then make the associated changes to firewall rules.
Check Time Settings on the Domain Controller running PDC Emulator
Many people know that the clients that talk to the Domain Controllers have to have the correct time, but it is super important that you are pulling a correct time source for your Domain Controllers.
Recommendation: Make sure the Domain Controllers, more specifically the Domain Controller with the PDC FSMO role is pulling its time from a trusted source. It might also be worth writing a script to monitor this as well.
Verify FSMO Role Holder(s), Global Catalog Servers, & Backups
Verify who is running the FSMO roles for your Domain(s). Make all DCs a Global Catalog if you have a single-domain forest. Verify how AD is being backed up.
Recommendation: Depending on your specific situation you may not be able to run all FSMO roles on one DC. In my jobs I have been able to. This allows you to target this DC as the DC to be backed up, snapshotted, etc. If you are running a single-domain forest, make sure all DCs are a global catalog.
Check Trusts
Check to see if there are any trusts configured for the domain.
Recommendation: If there are any trusts, figure out if they are still needed, and make sure there is documentation on why these trusts are setup and when they can be unconfigured.
Check Sites & Services for IP Configuration
Check AD Sites & Services for configuration of IP ranges. Make yourself familiar with how this setup and why it is setup the way it is.
Recommendation: Take notes on if Sites & Services is being used. If it is being used understand the network ranges and why it is configured the way it is. If priority is being given, understand why.
