Active Directory Security Assessment: What to Check First

What actually counts as an Active Directory security assessment?

Not a vulnerability scan. AD doesn't have a patch-level CVE feed you can run through a scanner and call it done. An active directory security assessment is a structured review of configuration state: trust relationships, delegation rights, certificate templates, Group Policy objects, and privileged group membership. The goal is to answer one question: if an attacker lands a foothold on a single workstation, how many hops to Domain Admin?

Most environments we look at answer that question in 2-3 hops. That's the number you're trying to move, not a compliance checkbox.

Where do most assessments start, and where do they usually find problems?

Start with these five areas, in this order, because each one feeds privilege into the next:

1. ADCS template misconfiguration. Check for templates where enrollee-supplied subject alternative names are enabled combined with client authentication EKU and low-privilege enrollment rights (the ESC1 pattern). This is still common in domains that stood up Certificate Services in the Windows Server 2012-2016 era and never revisited default template permissions. Run certutil -TCAInfo and pull template ACLs directly, or use an ADCS check tool that maps enrollment rights against EKU and SAN flags automatically. Manual review of this in a domain with 40+ templates takes a full day; automated checks do it in minutes.

2. Kerberoastable service accounts. Any account with a SPN and a weak or old password is roastable offline, no logon event generated. Query Get-ADUser -Filter {ServicePrincipalName -like "*"} and cross-reference password last set date. Accounts older than 2 years with SPNs are the highest-value targets; if any of those sit in Domain Admins or have DCSync rights, that's your top finding.

3. GPO drift and unlinked-but-dangerous policies. Group Policy is where privilege escalation hides in plain sight: a GPO granting local admin via Restricted Groups, a logon script with embedded credentials, or a policy that was supposed to be scoped to a test OU and got linked domain-wide by accident. This is the part manual assessments miss most often, because reviewing GPO XML by hand across 150+ policies doesn't scale. We built GPO X-Ray specifically for this: it diffs GPO state against a known-good baseline and flags drift (new Restricted Groups entries, changed audit policy, altered logon scripts) instead of requiring a human to read raw GPO reports.

4. Delegation chains. Unconstrained delegation on any non-DC computer object is a standing invitation for a Kerberos ticket-forwarding attack. Constrained delegation with protocol transition (TrustedToAuthForDelegation) is the next thing to check, then resource-based constrained delegation misconfigurations. Get-ADComputer -Filter {TrustedForDelegation -eq $true} is your first query.

5. Privileged group hygiene. Domain Admins, Enterprise Admins, and any custom group with AdminSDHolder-protected status. Count nested groups. We regularly see Domain Admins memberships that are 3x larger than the org believes, because nested group membership isn't obvious from the GUI.

How long should this take, and how often should we do it?

A manual first pass by an experienced AD engineer: 2-3 days for a single-domain forest, longer per additional domain or trust relationship. After the first pass, this should not be a once-a-year audit. GPOs and certificate templates drift weekly in any environment with more than a handful of admins touching them. Continuous drift detection (rather than point-in-time assessment) is the only way to catch a Restricted Groups change three days after it happens instead of eleven months later during next year's pentest.

What's the single most common finding across assessments?

Overprivileged service accounts with SPNs sitting in high-privilege groups. It combines two separate weaknesses (Kerberoastability and excessive privilege) into one finding that alone often justifies the whole exercise. If you find one, rotate the password to a long random value immediately and move the account out of Domain Admins, then reassess whether it needs domain-wide privilege at all.

One next step

Run the Kerberoasting query above in your own domain today: Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName,PasswordLastSet,MemberOf. Sort by password age. Any account older than 2 years with membership in a privileged group is your first fix, before you scope anything larger.