Securing Active Directory: Performing an Active Directory Security Review

Updated: Jun 17, 2021

During the Trimarc Webcast on June 17, 2020, Sean Metcalf covered a number of Active Directory (AD) components and areas that should be reviewed for potential security issues. The presentation included PowerShell code in the presentation and that code is incorporated in the PowerShell script Trimarc released for free that can be used to perform an AD security scan. This script is called Invoke-TrimarcADChecks.ps1 and only needs AD user rights to be run.

Download the Invoke-TrimarcADChecks,ps1 script below.

Note: You will need to change the the file type from .txt to .ps1 after downloading the file.

Note: Tool updated on 7/7/20

Download TXT • 26KB

The Invoke-TrimarcADChecks.ps1 PowerShell script is designed to gather data from a single domain AD forest based on our similar checks performed during Trimarc’s Active Directory Security Assessment (ADSA) engagement. It can be run against each domain in a multi-domain environment, but there is no guarantee that it captures the type of cross-domain (or cross-forest) data elements that may be involved. This script is meant to enable smaller organizations to more quickly identify potential issues. For larger, more complex AD environments, please contact Trimarc to talk about your concerns.

This script is designed for a single AD forest and is not designed to capture all data for a multiple domain forest. If this script is used for a single domain in a multi-domain AD forest, not all elements may be captured.

The Invoke-TrimarcADChecks.ps1 PowerShell script requires the following:

  • PowerShell 5.0 (minimum)

  • Windows 10 or Windows Server 2016 (or newer)

  • Active Directory PowerShell Module

  • Group Policy PowerShell Module

If the above requirements are not met, results will be inconsistent.

This script is licensed under BSD 3-Clause License and is provided as-is, without support.

The PowerShell script gathers domain data using the Active Directory PowerShell & Group Policy modules and displays some results on the screen. The data shown on the screen is also saved to a transcript log file and all captured data is also saved to csv/text files in c:\temp\Trimarc-ADReports (report folder is created upon script execution and this folder location can be changed).

This article covers the key AD security areas in which the Invoke-TrimarcADChecks.ps1 PowerShell script gathers data.

The Invoke-TrimarcADChecks PowerShell script gathers data for key AD security items in a domain:

  • User Account Issues

  • Domain Password Policy

  • Tombstone Lifetime & AD Backup Dates

  • Trusts

  • Duplicate SPNs

  • Group Policy Preference Passwords

  • AD Administration & Privileged Accounts

  • KRBTGT Account

  • Kerberos Delegation

  • Group Policy Object Owners

User Account Issues

There are several potential issues that Active Directory domain user accounts may have. Trimarc scans for these (and others) during our Active Directory Security Assessment (ADSA) engagement.

  • Inactive accounts – these are accounts that have not changed their password or logged on in a while (we typically focus on accounts with a combination of Password Age & User Logon Age over 90 to 180 days old)

  • Reversible Encryption – accounts configured with reversible encryption are stored in the AD database in a reversible format (which effectively means a clear-text version of the password is available).

  • Password Not Required – accounts created programmatically may have this set which means that technically a password is not required for the account to authenticate.

  • Password Never Expires – accounts with a password that is not subject to password expiration requirements. These accounts typically have very old passwords.

  • DES Kerberos Encryption Enabled – accounts enabled for Kerberos DES encryption.

  • Do not require Kerberos Pre-Authentication – accounts that don’t require Kerberos pre-authentication. There are known attacks against accounts with this configuration.

  • SID History – accounts with SID History configured

Trimarc Recommendation:

  • Disable and eventually delete inactive accounts

  • Remove the following from accounts:

  • Reversible Encryption

  • Password Not Required

  • Password Never Expires

  • DES Kerberos Encryption Enabled

  • Do not require Kerberos Pre-Authentication

  • Review accounts configured with SID History and clean up SIDs in SID History for accounts from domains that no longer have trusts configured with them.

Sample PowerShell Code & Results:

Domain Password Policy

The Domain Password policy determines how passwords are created and how often they need to be changed, etc. The AD default password minimum is 7 characters. Most AD environments we see have this set to between 8 and 10. Some are set to 0 or 3 or 5.

Password Spray attacks are effective against Active Directory due to bad passwords (often with short minimum requirements).Increasing password length can limit Password Spray effectiveness. Fine-Grained Password Policies (FGPP) provide additional flexibility, especially for admin and service accounts.

Trimarc Recommendation: Trimarc recommends that the Domain Password Policy be set to 12 characters (preferably 14 to 16 characters).

Sample PowerShell Code & Results:

The Active Directory module cmdlet “Get-ADPasswordPolicy” can easily capture the domain password policy.

Tombstone Lifetime

The AD Tombstone Lifetime determines how long deleted items exist in AD before they are purged. The default value was originally 60 days, but this was increased to 180 days starting with new AD forests created with Windows 2003 SP1. While the tombstone lifetime directly affects deleted items, it also has an impact on Domain Controllers. If a DC hasn’t replicated within the tombstone lifetime with another DC, it is effectively orphaned from the domain. Additionally, DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.

Trimarc Recommendation: Trimarc recommends configuring the Tombstone Lifetime to 180 days (or more if needed).

Active Directory Backups

Microsoft supported backups update a partition attribute to identify the last backup date for that partition. Not all systems that backup Active Directory set this attribute since they are likely not using a Microsoft supported method. In most scenarios, System State Backups on a Domain Controller are required to properly backup AD. We can easily check last Microsoft supported AD backup date/time by querying an attribute on each partition. Trimarc also identified that events like “Install From Media” creation on a DC can update AD backup date/time attribute.

Trimarc Recommendation:

Ensure you run a System State Backup on at least the FSMO role holders in the AD forest at least once a month and keep for at least 6 months.

Sample PowerShell Code & Results:


An Active Directory forest is the security boundary for AD. When a trust is configured, that extends the security boundary in include the system included in the trust since the trust extends the authentication boundary.

Trimarc Recommendation:

  • Review trust configuration & ensure that trusts are appropriate. Trusts should be reviewed at least annually to ensure they are still required

  • Bidirectional trusts should be scrutinized to ensure they need to be two-way trusts and still required.

  • Trusts with DMZ environments should be removed (if possible).

  • If a trust is required, look to shift to Selective Authentication which changes from Allow All to only those explicitly allowed to connect across the trust.

Selective Authentication changes the default behavior from allow any user across the trust to see everything to users require explicit approval to access resources otherwise they can’t view or access anything across the trust

Sample PowerShell Code & Results:

Active Directory Duplicate Service Principal Names (SPNs)

The Kerberos Service Principal Name (SPN) is effectively a signpost that connects a service on a server supporting Kerberos authentication with the service account. When there are duplicate SPNs, Kerberos authentication breaks since a Domain Controller can’t identify a single account associated with the SPN. Authentication will need to fallback to NTLM authentication. Duplication of the Krbtgt config is normal in a multiple domains in an AD forest.

Trimarc Recommendation:

Ensure there aren’t any duplicate SPNs (other than krbtgt).

Sample Code & Results:

Using SetSPN.exe we can discover any duplicate SPNs in the forest using the following command:

SetSPN -X -F

Any identified duplicate SPNs should be resolved since duplicate SPNs break Kerberos authentication which forces NTLM for authentication.

Group Policy Preference Passwords

Group Policy Preferences was released in the 2008 time-frame and included capability to provide and update credentials. These credentials were encrypted using AES256 which sounds good until you realize that a static key is used to encrypt them. The cpassword value in the GPP xml files is the encrypted password. Using a PowerShell function from PowerSploit, we can reverse this encryption and get the plain-text value. Since authenticated users have read access to Group Policies in the SYSVOL share on all DCs, anyone can view this information and get the passwords stored in GPP xml files, even across trusts. This is less of an issue now that Microsoft released a patch preventing the use of Group Policy Preference passwords. Old GPOs with these credentials remain though and Trimarc has identified a few in the past year during AD security assessments that would lead to either full AD compromise or compromising sensitive server data.

GPP capability with credentials:

  • Map drives (Drives.xml)

  • Create Local Users

  • Data Sources (DataSources.xml)

  • Printer configuration (Printers.xml)

  • Create/Update Services (Services.xml)

  • Scheduled Tasks (ScheduledTasks.xml)

  • Change local Administrator passwords

Trimarc Recommendation:

  • Ensure there are no Group Policy Preference passwords in SYSVOL.

Sample Code & Results:

The fast way to identify passwords in Group Policy Preferences is by using the findstr.exe command:

Findstr /S /I cpassword [SYSVOL_PATH]

A more comprehensive method is the Microsoft scanner provided here.


Active Directory Admin Account Checks

During Trimarc’s standard Active Directory Security Assessment, we focus on identifying “AD Admins” which includes members of the domain Administrators group, Domain Admins, Enterprise Admins, etc. These accounts have full AD rights and require careful protection.

The fastest way to identify AD admins is to run the following command which leverages the AD PowerShell module:

Get-ADGroupMember ‘Administrators’ -Recursive

Trimarc Recommendation:

  • Ensure passwords change regularly (every year)

  • Disable inactive account

  • Remove disabled accounts

  • Ensure no SPNs on accounts associated with people

  • Remove any computer accounts

  • Scrutinize Service Accounts

  • What do they do?

  • Where do they run?

  • What computers do they authenticate to?

  • What rights are actually required?

PowerShell Sample Code & Results:

First, we get the recursive membership of the domain Administrators group (which includes all the members of member groups).

Then, loop through them and get more detail from each member.

AD Admin Accounts Not Member of Protected Users

Protected Users is a new group created when the domain PDC Emulator is running Windows Server 2012 R2. Full Domain protection is only available when the domain functional level is 2012 R2.

Protected Users group provides additional protections:

  • Kerberos AES authentication only (No Kerberos DSE/RC4 or NTLM)

  • No Kerberos delegation (constrained or unconstrained)

  • Kerberos TGT set to 4 hours<