Skip to content

Active Directory Security Assessment: What It Covers & How

What an Active Directory security assessment covers, how it differs from config auditing, how it's run, and how findings map to DORA, NIS2 and ENS.

Yeray Martín
Yeray Martín · 16 min read

Active Directory Security Assessment: What It Covers and How

An Active Directory security assessment is a technical evaluation that finds the routes an attacker could actually walk from an ordinary user account to full control of your domain, then proves those routes are real by executing them under controlled conditions. It is not a configuration inventory and it is not log monitoring. It answers one question a compliance report has to answer for DORA, NIS2 and ENS: can someone reach Domain Admin from where they already are, and can you show you checked?

That question matters because the domain controller is where ransomware ends up. According to Microsoft, in more than 78% of human-operated cyberattacks the attackers compromise a domain controller, and in more than 35% of cases the machine that distributes ransomware at scale is a domain controller (Microsoft Security Blog, April 2025). An assessment exists to catch the path before an attacker does.

This guide covers what the term means, how it differs from an Active Directory audit, what a thorough assessment inspects, how it is run, which tools are involved, how findings map to compliance, what hardening follows, and how often to repeat it. If you are commissioning one, this is the buyer's view. If you want the operator's step-by-step attack methodology, that lives in the Active Directory pentesting guide.


What Is an Active Directory Security Assessment?

An Active Directory security assessment measures your directory's real exposure: whether a chain of permissions, tickets, certificates and delegation lets a low-privilege account reach Domain Admin, and whether that chain can be walked in practice. Three things get called "assessment" in the market, and they answer different questions.

  • Configuration audit. Checks settings against a baseline: password policy, stale accounts, GPO hygiene, protocol settings. Tools like PingCastle score how far your config drifts from a good state. Useful, but it tells you a setting looks wrong, not whether that setting hands over the domain.
  • Change and log audit. Watches who changed what and when: object modifications, group membership changes, sign-in events. Tools like Netwrix, SolarWinds ARM, ManageEngine and Lepide sit here. They answer "what happened", which is necessary for detection and forensics and required for several controls. They do not compute where an attacker could go next.
  • Exposure assessment. Models the directory as a graph and computes the routes to Tier 0, then validates the reachable ones by executing them. This is the category that produces a straight answer to "is there a live path to Domain Admin, and here is the proof."

The first two describe the state of the directory. The third describes what an attacker can do with that state. A config audit flags that a certificate template allows self-enrollment; an exposure assessment shows that this specific template, combined with a permission three hops away, lets any user issue themselves a Domain Admin certificate, and demonstrates it. Most regulated organizations need all three, because they answer different questions for different controls.


Active Directory Security Assessment vs Active Directory Audit: What's the Difference?

An Active Directory audit inventories configuration and logs changes; an Active Directory security assessment tests whether those configurations chain into a working attack path. The audit tells you a setting is off-baseline. The assessment tells you which off-baseline settings actually reach Domain Admin, and proves it by walking the route.

The two words get used interchangeably in search results, but they describe different work with different deliverables. An audit is a state description. An assessment is an exposure test. The table:

Configuration / change auditExposure assessment
Core questionIs this configured to baseline? What changed?Can an attacker reach Domain Admin from here?
MethodInventory settings, monitor eventsModel the graph, compute paths, execute the reachable ones
OutputDeviation list, change historyRanked attack paths with proof of exploitation
Sees ACL chains?Individual permissions, not the chainThe full multi-hop route
Typical toolsNetwrix, SolarWinds ARM, ManageEngine, Lepide, PingCastleBloodHound (mapping), exposure-validation platforms
Compliance roleDetection, forensics, config hygieneTechnical evidence of tested exposure

Neither replaces the other. Change auditing is genuinely required: DORA, NIS2 and ISO 27001 all expect you to detect and log security-relevant events, and a log audit is the right tool for that. It simply answers a different question. When a supervisor asks whether you have technically verified that your directory has no live route to full control, a change log does not carry that evidence. A validated attack path does.

The follow-on question most boards ask is how to fund the work. That is a separate conversation, covered in the business case for an AD security audit.


What Does an Active Directory Security Assessment Cover?

A thorough assessment inspects every object class and permission that can feed a path to Tier 0: privileged group structure, ACLs, Kerberos delegation, ADCS templates, trusts, GPO permissions, legacy protocols, credential hygiene, and the hybrid seam into Entra ID. The point is not to list settings; it is to find where they chain.

Use this as an Active Directory security checklist when you scope an engagement. Every item is a place where a legitimate configuration becomes an escalation route.

  • Privileged access and tiering. Domain Admins, Enterprise Admins, and the operator groups people forget (Account Operators, Backup Operators, Server Operators, Print Operators). Nested group membership that quietly reaches Tier 0. Whether an administrative tier model exists and holds.
  • ACL and permission chains. GenericAll, WriteDACL, WriteOwner, GenericWrite and ForceChangePassword edges that let a low-privilege object take over a higher one. These accumulate through migrations and delegations and are the most common backbone of a path to Domain Admin.
  • Kerberos delegation. Unconstrained delegation on any non-DC host, constrained delegation to sensitive services, and resource-based constrained delegation (RBCD) that an attacker can grant themselves by writing one attribute.
  • Active Directory Certificate Services. Template misconfigurations across the ESC family (ESC1 through ESC17). AD CS is present in roughly 90% of enterprise AD environments and is among the least-audited surfaces, because the PKI usually lives with a different team. See the ADCS ESC1 exploitation guide for how one template becomes a single-hop path.
  • Trusts. Domain and forest trusts, their direction and transitivity, and whether SID filtering is in place. A trust turns another domain's weaknesses into yours.
  • GPO and delegation permissions. Who can edit which Group Policy Objects, and which OUs those GPOs apply to. Write access to a GPO linked over Tier 0 is a path.
  • Legacy protocols and crypto. NTLMv1, RC4 in Kerberos, LDAP signing and channel binding, SMB signing. Weak crypto keeps attacks like roasting and relay viable.
  • Credential hygiene. Kerberoastable service accounts with old passwords and privileged group membership, AS-REP-roastable accounts with pre-auth disabled, GPP passwords in SYSVOL, reused local admin passwords, and accounts with replication rights (DCSync capability) that are not domain controllers.
  • Hybrid identity. The seam between on-prem AD and Entra ID: sync account exposure, connect server privileges, and paths that cross from on-prem into the cloud tenant or back.

A checklist scores each item in isolation. An assessment connects them, because the risk lives in the combination, not the individual line.


How Is an Active Directory Security Assessment Performed?

A security assessment runs in six stages: scope the engagement, discover the directory, review configuration, validate attack paths by executing them, report with compliance mapping, then remediate and re-test. The stage that separates an assessment from an audit is path validation: proving the route works rather than flagging that it might.

  • Scoping. Written authorization, the in-scope domains and their FQDN/NetBIOS names, an excluded-systems list (SCADA, medical devices, anything without failover), escalation contacts, and a time window. Some techniques are noisy; the security team should know when they run.
  • Discovery. Enumerate the full object graph from a domain-joined position: users, groups, computers, GPOs, trusts, ACLs, delegation, and ADCS presence. This is standard LDAP read access, since AD is built for it.
  • Configuration review. Score settings against baseline. This is the config-audit layer, and it feeds the graph rather than standing alone.
  • Attack-path validation. Compute the routes to Tier 0 and execute the reachable ones under controlled conditions, with guardrails and rollback, capturing evidence at each step. This is where a finding stops being "a template allows SAN specification" and becomes "we issued a Domain Admin certificate from this template and authenticated with it." Destructive CVE-class attacks (ZeroLogon, NoPac) are detected and flagged rather than fired in production.
  • Reporting and compliance mapping. An executive summary in business language, technical findings with CVSS and proof, attack-path diagrams, and every finding mapped to the relevant DORA / NIS2 / ENS control.
  • Remediation and re-test. Fixes prioritized by exploitability, then a re-run to confirm the path is closed rather than assumed closed.

The champion running or observing the technical stages will want the operator-level detail: enumeration commands, escalation techniques, and the BloodHound analysis that finds the chains. That is the Active Directory pentesting guide and, for the graph analysis specifically, AD attack paths with BloodHound.

Run a first pass yourself. ADscan LITE is free and source-available. From a single domain-joined Linux machine you can enumerate the directory, build the attack graph, and see which paths to Domain Admin show up before you commission a full engagement. Download it on GitHub.


What Tools Are Used in an Active Directory Security Assessment?

The tool depends on the question. Change auditors record what happened; config scanners score drift; graph mappers show where paths could exist; exposure-validation platforms execute the paths to prove they work. A complete assessment usually draws on more than one category.

  • Change and log auditors — Netwrix, SolarWinds ARM, ManageEngine, Lepide. Track object and membership changes and sign-in events. Strong for detection, forensics and change-control evidence. They do not compute or test attack paths.
  • Configuration scanners — PingCastle. Score the directory's configuration against a risk baseline and produce a posture number. Fast and useful for hygiene. They rate settings; they do not walk the route those settings create.
  • Attack-path mapping — BloodHound CE. Genuinely open source (Apache-2.0), it models AD as a directed graph and finds the shortest path from any node to Domain Admin. In most real environments such a path exists, and it is rarely a single hop. BloodHound shows the route exists; confirming it works is a separate step.
  • Consulting assessments — Semperis, Trimarc, Kroll, Mandiant. Expert-led manual or hybrid engagements. High quality and a point-in-time photo, priced and scheduled accordingly.
  • Exposure-validation platforms. This category models the graph and then executes the reachable paths to prove exploitation, mapping the result to compliance. Pentera and Horizon3 operate here across the whole network; ADscan operates here specialized on Active Directory.

Where does ADscan sit, honestly? It is not the only tool that runs on-premises, and it is not the only one that executes attacks rather than just mapping them. Pentera and Horizon3 do both too. The difference is the intersection: an Active-Directory specialist that executes the path (not only maps or scores it), runs on-premises, and maps every finding to DORA, NIS2 and ENS. ADscan LITE is free and source-available; it catalogues 103+ AD-specific techniques and executes roughly 70 of them end to end (ADCS coverage spans ESC1 through ESC17), flagging the destructive CVE-class attacks instead of firing them.


How Do Assessment Findings Map to Compliance (DORA, NIS2, ENS)?

A validated attack path is the technical evidence three frameworks now ask for: DORA's threat-led resilience testing, NIS2's active risk management, and ENS Alto's periodic verification of security status. A configuration list does not carry that evidence; a demonstrated path does.

  • DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. Article 9 requires verified technical controls over identity and access, and Article 13 obliges significant entities to run threat-led resilience testing. An executed path from a user account to Domain Admin is exactly the kind of technical verification a supervisor expects. Detail in DORA and Active Directory for financial entities.
  • NIS2 broadens cybersecurity risk-management duties and accountability to essential and important sectors, with material penalties for serious failures. The exposure lands once your country transposes the directive. See NIS2 and Active Directory compliance.
  • ENS Alto (Royal Decree 311/2022) requires periodic verification of systems' security status, and the CCN-CERT increasingly asks for real technical evidence rather than signed policy. Detail in ENS Alto and Active Directory compliance.

The common thread across the three: documented controls are not enough on their own; you have to demonstrate technically that your directory does not have a live route to full control. An assessment that executes the path and maps it to the specific control produces that record in a form an auditor accepts.


What Hardening Follows an Active Directory Security Assessment?

Active Directory hardening after an assessment is prioritized by exploitability, not by raw finding count: fix the settings that sit on a proven path to Domain Admin first, then close the rest. The assessment already ranked them, which is the point of validating paths rather than listing deviations.

How to secure Active Directory in the order that reduces risk fastest:

  • Cut the proven paths first. Every finding that sits on a validated route to Tier 0 is a priority-one fix, regardless of its standalone CVSS. Removing one edge often collapses several paths at once.
  • Fix dangerous ACLs. Remove excessive GenericAll / WriteDACL / GenericWrite grants that reach privileged objects. Review nested group membership so no ordinary group quietly reaches Domain Admins.
  • Constrain delegation. Remove unconstrained delegation where it is not required, scope constrained delegation tightly, and lock down who can write the attributes that configure RBCD.
  • Repair ADCS templates. Remove SAN specification from templates enrollable by low-privileged users, require manager approval where appropriate, and enforce channel binding on the enrollment endpoints.
  • Retire weak crypto and legacy protocols. Disable NTLMv1, remove RC4 from Kerberos, and enforce LDAP and SMB signing.
  • Rotate and separate credentials. Change long-lived service-account passwords, deploy managed service accounts, roll local admin passwords with LAPS, and remove replication rights from anything that is not a domain controller.
  • Enforce the tier model. Separate Tier 0 administration so a workstation compromise cannot cascade to the directory.

Then re-test. Hardening is not done when the change is applied; it is done when the assessment confirms the path is gone. That confirmation step is why exploitability-based prioritization beats a flat deviation list: you fix what actually mattered and you can prove you fixed it.


How Often Should You Run an Active Directory Security Assessment?

A point-in-time assessment is worth running at least annually and after any major change, but the real answer is continuous, because most paths to Domain Admin are created by ordinary operational changes between assessments. An annual engagement covers the day the auditor looked. Continuous validation covers the other 364.

The mechanism is simple. A migration grants a temporary GenericAll that never gets removed. An administrator publishes a certificate template to speed up a rollout. A service account is created with a weak password because rotating it would break an application. Each is a normal Tuesday, and each can open a new path the day after your annual photo was taken. The risk is not whether a path exists today; it is how long one stays live without anyone knowing.

Continuous exposure validation recomputes the routes to Tier 0 every time the environment changes, which is the enterprise CTEM model regulators are steering toward under DORA's "sustained" language and ENS's "periodic verification." It does not replace the annual expert engagement; it covers the gap between engagements.

See your own live paths. Request a free assessment: an ADscan engineer connects over VPN, runs it against your Active Directory, and hands you the report with compliance mapping the same day. No agents, no infrastructure changes. Book a walkthrough.


Active Directory Security Assessment FAQ

Is an AD security assessment the same as a pentest? They overlap but are not identical. A pentest is a broad, goal-driven engagement across the whole environment. An AD security assessment is focused specifically on the directory's exposure: the paths to Domain Admin and their compliance mapping. An exposure assessment executes those paths the way a pentest would, but scoped to the identity layer and repeatable, where a pentest is a one-off photo.

Can we do it ourselves? The first pass, yes. ADscan LITE is free and source-available; a member of your team can run it from a domain-joined Linux machine and see the attack graph and the top paths. What a self-run pass does not give you is the expert interpretation, the executed proof under guardrails, and the audit-ready compliance report. Teams typically run LITE to understand their exposure, then commission a full engagement for the evidence they can hand a supervisor.

How long does it take? A focused exposure assessment against a single domain runs in one to two hours from a single machine, including the report with compliance mapping. A traditional consulting engagement that delivers the same picture manually usually takes five to fifteen days. The gap is automation of the enumeration, graph analysis and path execution.

What is the difference between a config audit and an exposure assessment, again? A config audit tells you a setting deviates from baseline. An exposure assessment tells you which of those deviations chains into a working route to Domain Admin, and proves it by executing the route. The audit describes the state; the assessment describes what an attacker can do with that state. You usually want both, because they satisfy different controls.


If you run a regulated Active Directory and want the report mapped to your framework, request a free assessment — VPN in, run against your domain, findings the same day. To run a first pass on your own, download ADscan LITE on GitHub.

Active Directory Security Assessment: What It Covers & How | ADscan