Perform Active Directory security assessment using PowerShell

• Author
• Recent Posts

Krishnamoorthi Gopal

Krishna is working as a Senior System Administrator for a managed IT Service provider. He has 10 years of IT experience in the insurance and healthcare industries. Krishna focuses on Windows and Active Directory administration and works with various other technologies such as VMware, Azure, Hyper-V, and PowerShell.

Latest posts by Krishnamoorthi Gopal (see all)

• Windows security event log backup to SQL Server Express with PowerShell - Fri, Mar 18 2022
• Exploiting the CVE-2021-42278 (sAMAccountName spoofing) and CVE-2021-42287 (deceiving the KDC) Active Directory vulnerabilities - Thu, Feb 10 2022
• Perform Active Directory security assessment using PowerShell - Thu, Jan 6 2022

The security assessment script

Whatever fact does not fall under compliance is marked in red, as shown in the screenshot below. This script makes lightweight calls against AD to avoid the performance issues. It is designed for a single AD forest and is not designed to capture all the data in a multidomain forest. However, it can be customized to extend its scope.

AD Security Assessment report view

The following topics describe the assessment checks performed by the script.

User account issues

It is essential to audit and track the changes made to Active Directory users and groups to maintain security governance. The script uses the accounts that fall under the various security compliance facts, such as inactive user accounts and accounts configured with a legacy version of encryption.

Domain Users summary repor

Inactive accounts

When an inactive account is not disabled or remains outside password expiration limits, perpetrators who try to hack into an organization can use these accounts because their activities will go unnoticed. In addition, employees who leave the organization can misuse their login credentials to access network resources. The script identifies accounts that have not been updated for the last 180 days by using the LastLogonDate and PasswordLastSet attributes. You can modify this setting from config.ini.

$LastLoggedOnDate = $(Get-Date) - $(New-TimeSpan -days 180)  
$PasswordStaleDate = $(Get-Date) - $(New-TimeSpan -days 180)
Get-ADUser -Filter * -Properties * | Where { ($_.LastLogonDate -le $LastLoggedOnDate) -AND ($_.PasswordLastSet -le $PasswordStaleDate) }

AD user attributes to identify inactive accounts

Users with ReversibleEncryptionPasswordArray

The option to store passwords using reversible encryption provides support for applications that require the user's password for authentication. Anyone who knows the account password can misuse the account. Microsoft recommends disabling this setting through Group Policy using the Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\ policy if the option is no longer in use.

The following command displays the accounts with reversible encryption enabled in the domain:

Get-ADUser -Filter * -Properties * | Where { $_.UserAccountControl -band 0x0080 } 

User with ReversibleEncryptionPasswordArray enabled

Use Kerberos DES encryption types for this account

Accounts that can use DES to authenticate to services are at significantly greater risk of having that account's logon sequence decrypted and the account compromised, since DES is considered weaker cryptography. The command below helps identify the accounts that support Kerberos DES encryption in the domain.

Get-ADUser -Filter {UserAccountControl -band 0x200000}

Do not require Kerberos pre-authentication

In earlier versions, Kerberos allowed authentication without a password. Now, in Kerberos 5, a password is required, which is called "pre-authentication." An attack that focuses on accounts with the pre-authentication option disabled is called an AS-REP roasting attack.

The following command helps to retrieve all the accounts with pre-authentication disabled:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}

Kerberos pre authentication setting in AD

Review the domain password policy

It is important to review the domain password policy to determine whether the enforced configuration meets the benchmark standards. The script uses CIS -Windows Server 2019 Password Policy security standards for comparison. Optionally, you can keep the password standards in that INI file instead of inputting the values in the script, as shown in the screenshot below.

Config INI file with password standards

Input the domain in the command below to get the domain password policy information. If the server switch is not specified, it gets the details of the currently logged-on domain.

Get-ADDefaultDomainPasswordPolicy -Server “test.local”

Domain Password Policy report

Windows Server 2019 password policy security standards

Tombstone lifetime and backups

The tombstone lifetime option determines how long your backups can be used to perform data recovery in the event of a disaster in the IT environment. Microsoft recommends a value of 180 days. One of the benefits this provides is an increase in the useful life of backups.

The following command helps to identify the tombstone lifetime value and the last successful backup of each directory partition in the domain.

$ADRootDSE = get-adrootdse  -Server “Test.local”
$ADConfigurationNamingContext = $ADRootDSE.configurationNamingContext
 (Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$ADConfigurationNamingContext" `
-Partition "$ADConfigurationNamingContext" -Properties *).tombstoneLifetime 

$domaininfo = Get-ADDomain -Server “Test.local”
[string[]]$Partitions = (Get-ADRootDSE -Server $domaininfo.PDCEmulator).namingContexts
$contextType = [System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Domain
$context = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext($contextType,$($domaininfo.DNSRoot))
$domainController = [System.DirectoryServices.ActiveDirectory.DomainController]::findOne($context)
ForEach($partition in $partitions)
{
   $domainControllerMetadata = $domainController.GetReplicationMetadata($partition)
 $domainControllerMetadata.Item(“dsaSignature”)
   
} 						

Tombstone setting and backup onformation report

Unconstrained Kerberos delegation

When unconstrained delegation is configured, the userAccountControl attribute of the object is updated to include the TRUSTED_FOR_DELEGATION flag. When an object authenticates to a host with unconstrained delegation configured, the ticket-granting ticket (TGT) for that account is stored in memory. This is so that the host with unconstrained delegation configured can impersonate that user later, if needed. When the delegated servers are under the control of an attacker, the attacker can easily impersonate any server within the network using privileged TGT tokens that are cached locally.

Unconstrained deletion setting of a computer

The following query gets all the unconstrained computer objects in a domain other than Writable Domain (PrimaryGroupID=516) and Read-Only Domain Controllers (PrimaryGroupID=521)

Get-ADComputer -Filter { (TrustedForDelegation -eq $True) -AND (PrimaryGroupID -ne '516') -AND (PrimaryGroupID -ne '521') } 

Scan SYSVOL for Group Policy Preference passwords

Group Policy Preferences (GPP) came into use from Windows Server 2008. This feature helps secure the password for administrative tasks, such as creating a local user and mapping a network drive within the policy. Whenever a new GPP is created for the user or group account, the password is associated with an XML file that is stored inside the SYSVOL folder. As you can see in the figure below, this XML file holds cpassword for user raaz within the property tags in plain text.

XML configuration file of a group policy

Microsoft released a patch (KB2962486) to address this security gap, which prevents admins from putting password data into a Group Policy Preference. The following script helps to find any GPP items that were created in the past and left unnoticed until now:

$domaininfo = Get-ADDomain -Server "test.local"
$domainname = ($domaininfo.DistinguishedName.Replace("DC=","")).replace(",",".")
$DomainSYSVOLShareScan = "\\$domainname\SYSVOL\$domainname\Policies\"
Get-ChildItem $DomainSYSVOLShareScan -Filter *.xml -Recurse |  % {
If(Select-String -Path $_.FullName -Pattern "Cpassword"){  $_.FullName  }
} 

Review KRBTGT account information

The KRBTGT account is a domain default account that acts as a service account for the KDC service. In most cases, KRBTGT resets might be performed when Active Directory is compromised. Still, Microsoft advises changing the password at regular intervals to keep the environment more secure. The script checks and highlights whether the account password has not changed within the last 180 days.

$DomainKRBTGTAccount= Get-ADUser 'krbtgt' -Server $DCServer -Properties 'msds-keyversionnumber',Created,PasswordLastSet
If($(New-TimeSpan -Start ($DomainKRBTGTAccount.PasswordLastSet) -End $(Get-Date)).Days -gt 180) { 
Write-Host "Failed the test"
}

KRBTGT account info report

Audit privileged AD groups

In Active Directory, privileged accounts have controlling rights and permissions. They can carry out all designated tasks in Active Directory, on domain controllers, and on client computers. On the flip side, privileged account abuse can result in data breaches, downtime, failed compliance audits, and other bad situations. These groups should be audited often and cleaned up if any inappropriate members are added to them.

The script was written to pull out information about specific privileged groups. Click the count in the report table to see the list of group members.

Privileged AD Group Info report

$ADPrivGroupArray = @(
 'Administrators',
 'Domain Admins',
 'Enterprise Admins',
 'Schema Admins',
 'Account Operators',
 'Server Operators',
 'Group Policy Creator Owners',
 'DNSAdmins',
 'Enterprise Key Admins',
 'Exchange Domain Servers',
 'Exchange Enterprise Servers',
 'Exchange Admins',
 'Organization Management',
 'Exchange Windows Permissions'
)
foreach($group in $ADPrivGroupArray){
    try
    {
    $GrpProps = Get-ADGroupMember -Identity $group -Recursive -Server $env:COMPUTERNAME -ErrorAction SilentlyContinue | select SamAccountName,distinguishedName
        $GrpProps | % {
             $_.SamAccountName 
        }  
    }
    catch{
       $_.Exception.Message
    }
}

Run the script

The script gets the dynamic inputs from a file called config.ini. Edit the INI file according to your environment. The script and the INI file should be placed in the same directory; otherwise, the script will fail.

Config INI file details

After the initial changes in the INI file, you can run the script from PowerShell, as shown in the screenshot below. It generates the output in an HTML file called Reports_[Timestamp].HTML. The logging information is stored in a file called Log_[Timestamp].log".

Script logging from the PowerShell console

Script directory view post execution

The script source is published in the GitHub repository. You can view or download it using this link.

Conclusion

No organization with an IT infrastructure is immune from attack, but if appropriate, policies, processes, and controls can be implemented to secure Active Directory. One way is to assess Active Directory periodically, which helps to increase its security posture. Significantly, assessment helps to spot settings that do not meet the current security standards, namely, the CIS Benchmark.

Remediation guidelines and best practices can be defined based on the assessment outcome. I have written this script mainly to identify the vulnerable areas within Active Directory and generate information about vulnerabilities in a way that is viewable to audiences other than IT admins. I was not able to cover all the vulnerable spots in AD using this script, so there remain other vulnerabilities.

You can download the script here. The latest version can be found on GitHub.