How to Perform an Active Directory Security Assessment. Active Directory is the backbone of identity and access management in most enterprise environments, making its security paramount. This guide empowers us to conduct a comprehensive security assessment of our AD environment, identifying vulnerabilities and ensuring robust protection. These meticulously crafted steps safeguard our infrastructure and fortify our defence against potential cyber threats.
With the brief introduction, let’s start How to Perform an Active Directory Security Assessment.
Active Directory Security Assessment Checklist
Here’s a comprehensive Active Directory Security Assessment Checklist that covers all critical areas.
1. Account Security
- Disable or remove inactive user accounts.
- Identify and remove stale computer accounts.
- Ensure all accounts have strong, complex passwords.
- Enforce multi-factor authentication (MFA) for privileged accounts.
- Limit use of shared or generic accounts.
- Review and clean up service accounts – rotate passwords and limit privileges.
2. Privileged Access Management
- Identify and audit members of Domain Admins, Enterprise Admins, and Schema Admins.
- Use role-based access control (RBAC) where possible.
- Implement Just-In-Time (JIT) and Just-Enough-Access (JEA) for elevated privileges.
- Use Privileged Access Workstations (PAWs) for admin tasks.
3. Group Policy (GPO) Configuration
- Review and restrict GPO delegation.
- Enforce Account Lockout Policies.
- Enforce Password Policies (length, complexity, history).
- Audit logon/logoff events.
- Ensure User Rights Assignments are tightly scoped.
Also Read: Group Policy Best Practices – GPO Security Settings
4. Logging and Auditing
- Enable Advanced Security Auditing in Group Policy.
- Forward logs to a SIEM or central log collector.
- Audit changes to:
- Group memberships
- GPOs
- OU structure
- User permissions
- Monitor logs for:
- Kerberos ticket anomalies
- NTLM usage
- Lateral movement indicators
Also Read:Â How to Monitor and Audit Your Windows Server for Security Events
5. Active Directory Hardening
- Disable LM/NTLMv1 authentication.
- Enable LDAP Signing and Channel Binding.
- Enforce Secure LDAP (LDAPS).
- Use Protected Users Group for high-privileged accounts.
- Monitor and restrict use of PowerShell remoting and WMI.
6. Domain Controller Security
- Ensure DCs are on the latest OS version and patched.
- Limit access to Domain Controllers (physical and network).
- Restrict software installation on DCs.
- Implement Windows Defender Credential Guard.
- Enable Read-Only Domain Controllers (RODCs) where full DCs aren’t needed.
Also Read: Domain Controller Security Best Practices – Hardening (Checklist)
7. Organizational Unit (OU) Design & Permissions
- Review OU structure for logical separation.
- Minimize delegation of control on OUs.
- Ensure GPOs are scoped and linked correctly.
- Remove unnecessary inheritance or blocking.Â
8. DNS and Name Resolution
- Secure dynamic updates.
- Audit and clean up stale DNS records.
- Monitor for DNS zone transfers and unauthorized record changes.
9. Penetration Testing & Red Team Findings
- Regularly simulate AD attacks (e.g., pass-the-hash, DCsync, Kerberoasting).
- Use tools like PingCastle, BloodHound, Purple Knight, and SharpHound to assess AD exposure.
- Evaluate paths to Domain Admin using attack path analysis.
Also Read:Â Top 25 Best Kali Linux Penetration Testing Tools (Pros and Cons)
10. Documentation & Disaster Recovery
- Maintain up-to-date documentation of AD design, users, groups, and policies.
- Test and verify Active Directory backup and recovery procedures.
- Ensure AD Recycle Bin is enabled.
- Plan for Forest Recovery in case of a breach or ransomware event.
Also Read:Â Active Directory Disaster Recovery (Best Practices)
Active Directory Health & Security Assessment
Try our Active Directory Health & Security Assessment Tool. Monitor DC replication, DNS, Active Directory configuration, Operational checks, DC hardware, AD security assessment, GPO checks, permissions & more..
Perform an Active Directory Security Assessment
Active Directory (AD) is the backbone of identities for many organizations worldwide. Still, it often needs to be managed better, which allows attackers to compromise it. Recovery is costly, so we need to enforce complete security.
AD Security Assessments (ADSA) contain different technical security controls and procedures to protect AD. ADSA aims to help our team work together to improve AD’s security posture without pitching a third-party vendor or trying to sell us a security product.
Baseline Security References
The following baseline securities explained in this article came from Microsoft Baseline Security and the Center for Internet Security (CIS).
Microsoft Baseline Security and the CIS are 2 pivotal elements in the cybersecurity landscape. Each plays a critical role toward stronger security postures.
Hardening Settings for Domain Controllers
Hardening the settings for Domain Controllers are essential for bolstering the security of an entire network. They manage user authentication and system authorizations but they are prime targets for cyber attacks.
Every Domain Controller (DC) has the Default Domain Controllers Policy. However, this GPO creates different escalation paths to Domain Admin if we have any members in Backup Operators or Server Operators. Administrators must adjust the default domain group policy to configure user rights.
The policy Network security: LAN Manager authentication level needs more attention because it breaks things in production. We must test this policy thoroughly before deploying it. Also, two NTLM audit settings need to be enabled to track down the use of NTLM.
| Network security: Restrict NTLM: Audit Incoming NTLM Traffic | Enable auditing for domain accounts |
| Network security: Restrict NTLM: Audit NTM authentication in this domain | Enable all |
Rotating KRBGT Account Password
A procedure for rotating the Kerberos Ticket Granting Ticket (KRBTGT) password needs to be in place. KRBTGT is the security principal for the Key Distribution Center (KDC). The KDC encrypts a user’s TGT with the key it derives from the KRBTGT account’s password, in other words, with the NT hash of the KRBTGT account.
An attacker who manages to get the NT hash of the KRBTGT account can create Golden Tickets to impersonate every User in the domain, but this requires Domain Admin or equivalent. The best practice is to reset the KRBTGT account’s password twice every half-year.
Here’s a sample PowerShell script to reset the KRBTGT account. This script should run from a domain controller or a machine with the Active Directory module for Windows PowerShell installed and imported. Also, make sure that you have the necessary administrator privileges to make this change.
function Reset-KrbtgtPassword {
# Retrieve the krbtgt account
$krbtgt = Get-ADUser -Identity krbtgt -Properties SamAccountName
if ($krbtgt -ne $null) {
Write-Host "krbtgt account found. Proceeding with password reset."
# Generate a new random password
$newPassword = [System.Web.Security.Membership]::GeneratePassword(20, 2)
# Reset the krbtgt account password
Set-ADUser -Identity $krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText $newPassword -Force) -Reset
Write-Host "The krbtgt account password has been reset successfully."
} else {
Write-Host "krbtgt account not found."
}
}
# Execute the function to reset the krbtgt password
Reset-Krbtgt
Try InfraSOS Active Directory Replication Status Tool
Monitor your Active Directory Health Status, Domain Controller Replication, DNS & Active Directory Security with our AD Health tool.
Rotating DSRM Account Password
Directory Services Restore Mode (DSRM) is the break-glass account of Domain Controllers. We must define a password for the account when promoting a member server to a DC. DSRM is like the Local Administrator on a DC. The password of the DSRM account is rarely changed, and it is best practice to rotate this password.
To reset the password of the DSRM account- log onto the Domain Controller. Then launch the Command Prompt with elevated rights, ensuring we have administrative privileges for the tasks ahead. With Command Prompt or PowerShell, open and run under these elevated rights, then proceed to reset the DSRM account’s password with the following steps:
- Inside the CLI terminal, type Ntdsutil
- Set DSRM password
- Reset password on Server <servername>
- Type the new password of the DSRM and enter
- Re-type the password of DSRM to change the password and Enter
- Type q (quit) and Enter
- Type q again and Enter
Improve Auditing Rules
Domain Controllers are crucial servers, and solid auditing must be in place to track changes. Audit policies are needed to have better visibility when tracking potential malicious behaviour. Windows Security Baseline has provided some guidance around auditing policies.
More than default auditing policies of the Domain Controller are required. It gives limited visibility into changes that we make to the Domain Controller. We recommend the following audit policies for configuration for domain controllers.
Start with creating a GPO and configure the following Advanced audit policies:
| Policy Path | Policy Setting | Configured Setting |
|---|---|---|
| Account Logon | Â | Â |
| Audit Kerberos Authentication Service | Success, Failure | Success and Failure |
| Audit Kerberos Service Ticket Operations | Success, Failure | Success and Failure |
| Audit Other Account Logon Events | Success, Failure | Success and Failure |
| Account Management | Â | Â |
| Audit Computer Account Management | Success, Failure | Success and Failure |
| Audit Security Group Management | Success, Failure | Success and Failure |
| Audit User Account Management | Success, Failure | Success and Failure |
| Logon/Logoff | Â | Â |
| Audit Logoff | Success | Success |
| Audit Logon | Success, Failure | Success and Failure |
| Audit Special Logon | Success | Success |
| Object Access | Â | Â |
| Audit Directory Service Access | Success, Failure | Success and Failure |
| Audit File System | Success, Failure | No Auditing |
| Policy Change | Â | Â |
| Audit Authentication Policy Change | Success | Success |
| Audit Authorization Policy Change | Success | Success |
| System | Â | Â |
| Audit Security State Change | Success | Success |
| Audit Security System Extension | Success | Success |
| Audit System Integrity | Success, Failure | Success and Failure |
Securing the Local Administrator Account
An Administrator account is in the local User group in every AD environment. Should this account be disabled or not? According to the official Microsoft documentation:
Use of a domain’s Administrator account should be reserved only for initial build activities, and possibly, disaster-recovery scenarios.
Many admins have deactivated this account, but we recommend that we enable the Administrator account because it can log on without access to a Global Catalog server.
Before enabling this account, we recommend we create a GPO with the policies below and link it to the workstations and servers OU to deny logon access for the Administrator account. Since this account is a Domain & Enterprise Admins group member, it accesses everything and does the following:
- Deny access to this computer from the network
- Deny log on as a batch job
- Deny log on as a service
- Deny log on through Remote Desktop
Managing ACEs on Domain Controllers
Fixing the Access Control Entries (ACEs) in the Domain Controller is crucial for maintaining the security and integrity of the Active Directory (AD) environment. Incorrect or overly permissive ACEs exposes sensitive data, grants unauthorized access, and allows attackers to escalate their privileges within the network. Ensure we correctly configure the ACEs against such vulnerabilities.Â
ACEs on Domain Controllers OU
ACLs we set on the organizational unit (OU) of Domain Controllers are a risk because an attacker can link an arbitrary GPO or disable a GPO. It weakens the security of the Domain Controllers.
- Do not delegate permissions on the OU of the Domain ControllersÂ
- Look if permissions have been delegated on the OU of the Domain Controllers and remove them as soon as possible
ACEs on Domain Controller Computer Objects
Users with GenericAll or equivalent on the DC Computer Objects can perform a Resource-Based Constrained Delegation attack to get code execution on the Domain Controller.
Suppose a user writes to the property ms-DS-Allowed-To-Act-On-Behalf-Of-OtherIdentity on the DC computer object. It can act on behalf of that service, which is the DC in this example. This property allows an attacker to move laterally to the DC and get code execution.
ACEs of Users and Groups Part of Domain Admins
Wrong delegated permissions set on Domain Admin users are a considerable risk because certain users or groups might be able to take over an account and impersonate Domain Admins. To start, use the Get-ADGroupMember PowerShell command to get the members of domain administrators.
Remove all the delegated permissions set on users in the groups above.
ACEs Set on DNS Objects
By default, Domain Controllers are DNS servers. Security Researchers have discovered a way to execute a DLL as a SYSTEM on the DC to escalate privileges to a Domain Admin. Since DnsAdmins has Full control permission on the DNS Object by default, Everyone from DnsAdmins can become a Domain Admin.
ACEs Set on Group Policies Linked to DC
Manage all group policies we enforce from an administrator’s perspective. Do not delegate permissions to these GPOs because everyone who edits these GPOs can become a Domain Admin.
ACEs Set on Domain Object
Delegating rights on the Domain Object is not something we should consider because it creates different escalation paths for Domain Admin where admins decide to delegate rights on the Domain Object by assigning users or groups Full control permissions because it makes the job more convenient.
Users with GenericAll or equivalent replicate secrets from the Domain Controller and obtain credentials for every User in AD with the Administrator account. This process is an example that many organizations have in their environment, which are the default Exchange groups with broad permissions in AD. This group, known as Exchange Trusted Subsystem, has Modify permissions right on the Domain Object and is a member of the group Exchange Windows Permissions.
- Exchange Trusted Subsystem and Exchange Windows Permissions don’t need to have modify permissions on the Domain Object.
- Suppose we remove Modify permission from the Exchange Trusted Subsystem. A small functionality breaks in the Exchange Management Console, assigns Send as permissions to users. We delegate this to resolve the problem.
- Look if other users and groups have been delegated on the Domain Object, and try to see if we can remove them and find another way.
Did you find How to Perform an Active Directory Security Assessment informative and well lectured? We hope so. Let’s conclude below.
How to Perform an Active Directory Security Assessment Conclusion
After remediating the relevant AD Domain Controller security settings do not stop there. Active Directory is just one of many vectors where bad perpetrators can attack our infrastructure. Read more on Microsoft Security Guide and review all the CIS benchmark policies. Armed with these insights, we are ready to fortify our Active Directory environment against the ever-changing landscape of cyber threats.
Try InfraSOS for FREE
Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool
- Free 15-Days Trial
- SaaS AD Reporting & Auditing Solution
