Active Directory Security Best Practices: An Operator Checklist for Hardening AD

Active Directory Security Best Practices: Operator Checklist

This checklist is for engineers who own the domain, not for people still deciding whether AD matters. Each item follows the same four-field format: rationale, bad state, good state, and the configuration knob. No abstractions.

Use Retrievy's GPO X-Ray to surface the delta between your current Group Policy state and the settings listed below, so you can prioritize by blast radius rather than gut feel.

1. Enforce Kerberos AES-only encryption

• Rationale: RC4 tickets are crackable offline. Kerberoasting attacks target service accounts using RC4-encrypted TGS tickets.
• Bad: DES and RC4 encryption types are enabled on user and service accounts.
• Good: Only AES128 and AES256 are enabled; RC4 and DES are explicitly disabled on all accounts.
• Knob: GPO path Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos — uncheck DES_CBC_CRC, DES_CBC_MD5, and RC4_HMAC_MD5.

2. Restrict membership in Domain Admins

• Rationale: Every extra member of Domain Admins is a lateral-movement pivot waiting to happen. Most environments have 3x more members than they need.
• Bad: Service accounts, helpdesk accounts, or personal admin accounts sitting in Domain Admins permanently.
• Good: Fewer than five named individuals, reviewed quarterly, with no service accounts present.
• Knob: Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select Name, SamAccountName — review output and remove non-essential members. Enforce via Restricted Groups GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups.

3. Enable Protected Users security group for privileged accounts

• Rationale: Members of Protected Users cannot authenticate with NTLM, cannot use unconstrained delegation, and receive short-lived Kerberos tickets, cutting off a large class of credential-theft paths.
• Bad: Tier-0 admin accounts not in Protected Users; NTLM authentication still available for those accounts.
• Good: All Domain Admins, Enterprise Admins, and Schema Admins are members of Protected Users.
• Knob: Add-ADGroupMember -Identity "Protected Users" -Members <account> — requires Windows Server 2012 R2 or later domain functional level.

4. Disable NTLM where possible, audit where not

• Rationale: NTLM is vulnerable to pass-the-hash and relay attacks. Environments that never audit NTLM usage cannot quantify the risk of disabling it.
• Bad: NTLM unrestricted across the domain; no audit logging; no baseline of which systems still depend on it.
• Good: NTLM audited first (Audit NTLM policy active for at least 30 days), then restricted to specific servers via exception, with a roadmap to elimination.
• Knob: GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM — set to Audit all first, then Deny all after clearing dependencies.

5. Audit and clean up Service Principal Names on sensitive accounts

• Rationale: Any account with an SPN is Kerberoastable. SPNs on Tier-0 accounts are high-value targets.
• Bad: Domain Admin accounts with SPNs registered, often as a legacy artifact from old service deployments.
• Good: No SPNs on privileged user accounts. Service SPNs exist only on dedicated, low-privilege service accounts with long, random passwords (25+ characters).
• Knob: Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName | Where-Object {(Get-ADGroupMember "Domain Admins").SamAccountName -contains $_.SamAccountName} — remove SPNs with Set-ADUser -Identity <account> -ServicePrincipalNames @{Remove="<SPN>"}.

6. Block unconstrained Kerberos delegation

• Rationale: A computer or service account configured for unconstrained delegation caches TGTs for every user who authenticates to it. Compromising that host yields tickets for any user, including Domain Admins.
• Bad: Any non-domain-controller computer account has TrustedForDelegation set to True.
• Good: Only domain controllers hold unconstrained delegation. All other services use constrained delegation (KCD) or resource-based constrained delegation (RBCD).
• Knob: Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation — clear the flag with Set-ADComputer -Identity <computer> -TrustedForDelegation $false.

7. Harden LDAP signing and channel binding

• Rationale: Without LDAP signing, an attacker who can intercept traffic can relay authentication to the domain controller. CVE-2017-8563 demonstrated this class of attack.
• Bad: Domain controllers accept unsigned LDAP binds; channel binding is not enforced.
• Good: LDAP signing required; LDAP channel binding set to Always.
• Knob: GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements set to Require signing. Channel binding: set registry key HKLM\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding to 2.

8. Audit and restrict ADCS certificate template permissions

• Rationale: Misconfigured Active Directory Certificate Services templates are one of the highest-yield privilege escalation paths in Windows environments. ESC1 through ESC8 are well-documented escalation patterns.
• Bad: Certificate templates allow low-privileged users to specify a Subject Alternative Name (SAN), enabling impersonation of any user including Domain Admins.
• Good: Only privileged accounts can enroll in templates that allow SAN specification. Manager approval is required for sensitive templates. Unused templates are removed.
• Knob: Use Certify.exe find /vulnerable (from Specterops) or Retrievy's ADCS check to enumerate risky templates. Restrict enrollment permissions in the Certificate Templates MMC snap-in (certtmpl.msc).

9. Enable and review audit policy for privileged operations

• Rationale: Without audit logging, you cannot detect or reconstruct attacks. The minimum viable audit surface covers account logon, directory service changes, and privilege use.
• Bad: Default audit policy only; no advanced audit policy configured; Security event log capped at 20 MB and overwriting.
• Good: Advanced Audit Policy configured via GPO, Security event log set to 1 GB or forwarded to a SIEM, and retention set to at least 90 days.
• Knob: GPO: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration — enable at minimum: Audit Account Logon, Audit Directory Service Changes, Audit Privilege Use, Audit Logon, Audit Group Membership.

10. Enforce tiered administration and deny cross-tier logon

• Rationale: Tier-0 credentials used on Tier-1 or Tier-2 systems expose those credentials on lower-trust hosts. A single compromised workstation should not be a path to domain compromise.
• Bad: Domain Admins log on interactively to workstations and member servers. Admin accounts are shared across tiers.
• Good: Separate admin accounts per tier. Tier-0 accounts blocked from logging on to anything below Tier-0 via logon restrictions.
• Knob: GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Deny log on locally and Deny log on through Remote Desktop Services — add Tier-0 admin groups to these settings on Tier-1 and Tier-2 OUs.

Work through this list top to bottom. Items 1, 6, and 8 carry the highest remediation value for most environments and should be addressed within the first 30 days. Items 4 and 10 require coordination with application owners and are typically 60 to 90 day efforts.