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.
How to 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 our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of reports available to gain control of your IAM.
Improve your AD & Entra ID security & compliance.
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
