In most Windows-based organizations, Active Directory is the map of who can do what. It decides which accounts reach which servers, who can reset whose password and which groups hold administrative rights. When an intruder lands on a single workstation, the directory usually decides whether that stays a minor incident or becomes a full compromise. An Active Directory security assessment looks at the directory the way an attacker would, so you can close the paths before anyone uses them.
What an assessment examines
A thorough review combines configuration analysis with hands-on testing from a realiztic starting point, usually a standard domain user on a normal workstation. Testers look at:
- Privileged groups, their membership and how membership is controlled
- Permissions on users, groups, organizational units and Group Policy objects
- Service accounts, how they authenticate and what they can reach
- Certificate services templates and enrolment permissions
- Domain and forest trusts, including links to cloud identity
- Password and lockout policies, and how local administrator accounts are managed
- Protocols and authentication methods still enabled for compatibility
- Logging and monitoring of sensitive directory changes
The aim is to find attack paths: chains of individually small permissions that together lead somewhere serious.
Common weakness classes
The table below summarizes issues that appear regularly. It describes the problem and the defensive fix, not how to exploit it.
| Weakness class | Why it matters | Typical fix |
|---|---|---|
| Kerberoastable service accounts | Service accounts with weak passwords can have their credentials recovered offline by any domain user | Use group managed service accounts or long random passwords; reduce privileges |
| Accounts without pre-authentication | Similar offline password exposure for affected user accounts | Re-enable Kerberos pre-authentication; review why it was disabled |
| ACL misconfigurations | Rights such as reset-password or write-membership granted to broad groups create hidden escalation routes | Review delegations; remove inherited or legacy rights; restrict to named admin groups |
| AD CS misconfigurations | Loose certificate templates or enrolment rights can let a user obtain a certificate that authenticates as someone else | Harden templates, restrict enrolment, require manager approval for sensitive templates |
| Credential reuse and shared local admin | The same local administrator password on many machines lets one compromise spread widely | Deploy a local admin password solution; remove standing local admin rights |
| Legacy protocols | Older authentication and name-resolution protocols allow credential capture or relay | Disable where possible; enforce signing; plan retirement of dependent systems |
| Unconstrained delegation | Servers trusted to act on behalf of any user become high-value targets | Move to constrained or resource-based delegation; protect sensitive accounts |
| Stale and over-privileged accounts | Old admin accounts and forgotten group memberships widen the attack surface | Regular access reviews; tiered administration model |
How testing is done safely
Directory testing touches the system everyone depends on to log in, so care matters. A well-run assessment:
- Starts read-only. Most analysis is enumeration of objects and permissions that any user can already see.
- Agrees risky steps in advance. Anything that could lock accounts or change objects is discussed and scheduled with you.
- Avoids password spraying without limits. Lockout thresholds are confirmed first, and attempts stay well below them.
- Cleans up. Any test objects or changes are recorded and removed, and the report lists them.
- Coordinates with monitoring. Your detection team knows the source hosts and accounts, unless you have chosen to test detection.
Written authorization is signed before testing begins, as with every engagement.
Preparing for an assessment
- Provide a standard domain user account and a typical joined workstation or VPN access
- Share a high-level diagram of domains, forests, trusts and any cloud identity synchronization
- List systems that are fragile or business-critical so testers can avoid disrupting them
- Confirm account lockout policy and any monitoring that might trigger an automated response
- Name a directory administrator who can answer questions during testing
Our scoping guide covers the general preparation steps that apply to any internal test.
Reading the results
A useful AD report does more than list settings. It shows attack paths as a sequence: which starting account, which permission, which next object, and where the path ends. That lets you break a path at its cheapest point. Removing one unnecessary delegation can close several routes at once.
Expect findings to be rated with CVSS and explained in context. Our CVSS v4.0 guide explains why a technically Medium finding can still sit on the most important path in your directory.
Questions to ask in the debrief
- Which single change would close the largest number of paths?
- Which findings would a defender notice today, and which would pass silently?
- Are any issues inherited from a legacy design that affects other domains or forests?
- What should we monitor while longer fixes are in progress?
Answers to these turn a long technical report into a short, ordered plan your directory team can start on the same week.
Turning findings into lasting improvements
Quick wins
Reset weak service account passwords, remove stale admin group members, fix the most dangerous permission delegations and harden risky certificate templates. These often take days rather than months.
Structural changes
Adopt a tiered administration model so domain admin credentials are never used on ordinary workstations. Introduce managed service accounts, a local admin password solution and privileged access workstations.
Ongoing hygiene
Schedule access reviews, monitor changes to sensitive groups and objects, and plan retirement of legacy protocols. Directories drift over time, so a periodic reassessment is worth building into your testing cadence.
Once fixes are in, verify them. The remediation and retesting guide explains how to scope a retest that proves paths are closed.
Hybrid identity and the cloud
Many organizations synchronize on-premises accounts with a cloud directory. That link can carry a compromise in both directions. Include synchronization servers, federation services and cloud administrator roles in scope where possible. If your workloads also run in public cloud, the cloud penetration testing checklist covers the identity and configuration side there.
Frequently asked questions
Does an AD assessment disrupt users?
It should not. Most work is read-only enumeration and analysis. Any step that could lock accounts or change objects is agreed in advance and run in a window you approve.
Do we need an internal network test as well?
They overlap. An AD assessment focuses on identity paths and configuration; an internal network test also covers hosts, services and segmentation. Many organizations combine them.
What about hybrid identity with a cloud directory?
Include synchronization servers and the trust between on-premises and cloud identity in scope, because weaknesses there can let a compromise move in either direction.
Want to see the paths through your directory before an attacker does? Explore our Active Directory pentest and internal network pentest, or request a quote.