AD security assessment vs internal pen test

Active Directory security assessment or internal penetration test: which one first?

If you must choose one first, start with a configuration-led Active Directory and Entra ID assessment, then run an internal penetration test once the obvious paths are fixed or documented. The assessment answers what privileged paths exist on paper: who sits in tier 0 groups, where delegation grants control over domain controllers or admin accounts, which service accounts hold rights they do not need, and how hybrid synchronization connects on-premises identities to the cloud. The penetration test answers a narrower question: starting from a standard user account, can a tester actually climb to domain administrator? Each finding that looks serious on a report is only worth fixing at the priority its real exploitability justifies, and the two methods give you different evidence about that.

Choose the configuration review when you have not mapped your tiering model, when acquisitions or long-lived delegations have accumulated, or when you need a baseline you can measure against later. It is also the cheaper route to a complete list of control plane exposures. Choose the internal penetration test when leadership needs proof that a compromised workstation leads to domain compromise, or when your detections need validating against techniques an attacker would use. NIST SP 800-115 describes internal testers starting with a standard employee's access and attempting escalation, for example from system administrator to domain administrator, and NIST notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk.

A practical sequence is to run the assessment first, remediate or formally accept the tier 0 and delegation findings, then schedule the penetration test against the hardened estate so it tests what remains. Confirm with each provider that the test includes Entra Connect and the hybrid sync path, and that the scope states whether the tester begins from a standard user. Ask the assessor to show which Microsoft enterprise access model planes each finding touches, because that mapping is what lets you justify the order to auditors and to your board.

How an Active Directory security assessment and an internal penetration test compare

This table compares an Active Directory and Entra ID configuration-led assessment with an internal penetration test that starts from a standard user and tries to escalate. Read each row as the question the work answers, then check the rules of engagement and the provider's method, which change several rows.

Dimension	Active Directory security assessment	Internal penetration test (standard user start)
Goal	Confirm that tiering, delegation, group membership and privileged paths match the intended design	Show whether an attacker with ordinary access can reach domain or tenant control in practice
Starting access	Usually read-only directory access with an audit account, plus configuration exports and design documents	An ordinary employee account on the internal network, per the scope agreed in the rules of engagement
Method	Collects directory state and evaluates it against the tier model, delegation settings and privileged group membership	Uses discovery, credential and relationship abuse and misconfiguration exploitation to attempt privilege escalation
Risk to production	Low, because the work is largely passive and read-only; confirm which collection tools and query volumes the provider will run	Higher, because exploitation touches live domain controllers and identities; the rules of engagement should define permitted actions and stop conditions
Question it answers	Are the privilege boundaries designed and configured the way the enterprise access model intends?	Can a realistic path from a standard user reach administrative control, and which configuration gaps make that path work?
Typical output	Findings mapped to tiers and configuration settings, with remediation owners and evidence of the state observed	Demonstrated attack paths with the steps taken, affected accounts and a list of the controls that failed or were absent
Feedback to monitoring	Shows which privileged changes and anomalies detection should cover, and where audit logging is missing	Shows which techniques generated alerts, which went unseen, and which detections need validation after retest

How Microsoft's enterprise access model frames an Active Directory assessment

Microsoft's enterprise access model gives a configuration review its structure: a tier hierarchy, continuous auditing and monitoring. The model calls for a hierarchy that prevents control of higher planes from lower planes, so a reviewer should map every tier boundary in the directory and ask whether anything in a lower tier can reach a higher one. Start with the tier definitions in the Microsoft Learn enterprise access model page and confirm them against your own design, because tier names and scope have changed over time and your environment may draw the lines differently. Then trace where tier 0 identities, groups and servers are administered from, including domain controllers, AD FS, Entra Connect servers and the accounts that manage them.

The second idea is continuous auditing for configuration vulnerabilities that enable inadvertent privilege escalation. For delegation, this means reviewing who holds write rights over groups, GPOs, OUs and service accounts that sit on a higher plane, and whether delegated administrators can change ACLs that indirectly grant control of tier 0. A configuration review checks these settings as they are written, usually with directory exports and rights analysis. The third idea is monitoring for anomalies, which a review can only partly test. Ask whether tier 0 sign-ins, group membership changes and ACL edits generate alerts, and confirm that the logs are retained and reviewed.

A penetration test asks whether the hierarchy holds in practice. A tester starting from a standard user account, the position NIST SP 800-115 describes for an internal test, will chain small weaknesses such as a helpdesk account with password reset rights, a stale service account or a misplaced delegation to reach domain administrator. If that chain succeeds, the model's boundary has failed even though each setting looked acceptable on paper. Agree the test's rules of engagement and detection expectations before work starts, and plan for the tester to be detected, since that outcome also tests the monitoring idea.

What each approach finds and misses

A configuration review and an internal penetration test answer different questions about the same directory. The cards below separate what each one surfaces, what it cannot see, and where the two overlap, so the scope you write reflects both.

Tier violations and control plane exposure

A configuration review maps accounts, groups and hosts against the tier boundaries in Microsoft's enterprise access model, which expects a hierarchy that stops control of higher planes from lower planes. Look for privileged identities that log on to standard workstations, service accounts with domain-level rights, and management paths that cross tiers. NIST SP 800-115 treats review techniques as passive with minimal risk to systems, so the reviewer can run this against production without exploiting anything.

Excessive delegation and risky group nesting

Delegated rights over organizational units, GPO edit permissions and nested group memberships often grant more power than the group name suggests. A review enumerates effective permissions and flags groups that inherit administrative rights through a chain of nesting. Confirm with the client which delegations were intentional, because many of these are legacy decisions that nobody has revisited. This finding describes a capability on paper; it does not show that a standard user can use it.

Unmanaged privileged accounts

Review output often shows privileged accounts with non-expiring passwords, stale administrator accounts from former staff, and shared credentials for service identities. These are easy to list and hard to explain away. Ask the client to confirm which accounts are supposed to hold privilege, who owns each one, and whether any were created outside the normal provisioning process. A review can state that the account exists with the right; it cannot confirm whether anyone has used it.

Exploitable chains that depend on live state

A review misses paths that only exist during a particular session, such as a privileged user who is logged on to a host where a standard user already has code execution, or a credential left in a file share that a tester finds by browsing. These chains depend on live state and on how an attacker moves between systems. A penetration test starting from a standard employee account, as NIST SP 800-115 describes, is the method that surfaces them. Ask the provider whether they will test from a standard user and whether lateral movement is in scope.

Proven escalation paths from a standard user

A penetration test that begins with a standard user account shows which escalation paths work in the target environment, step by step. NIST SP 800-115 describes penetration testing as using real exploits against production systems and data, which is why it is classed as high risk. Each path in the report should include the starting account, the technique used, the privilege reached and the evidence captured. Ask for that evidence format before the engagement starts, so the output can be compared against the review.

Paths outside the agreed scope and window

A penetration test can only prove paths the tester reached within the agreed scope, accounts, hosts and time. A path through a system that was excluded, or one that needed more days of testing than the window allowed, will not appear in the report, even if a review would have flagged it. Ask the provider to list excluded systems and to state which paths were attempted. Pair the test with the configuration review so that unreached items have a documented status rather than an unknown one.

Why hybrid synchronization paths belong in the scope

A review of on-premises Active Directory that stops at the domain controllers misses the path that links it to the cloud. Microsoft Entra Connect synchronizes on-premises AD with Microsoft Entra ID using password hash synchronization, pass-through authentication or federation with AD FS. Each option creates a different trust and attack path, so the sync method belongs in scope from the start. Microsoft also states that Entra Cloud Sync is the future of synchronization, which means the review should record whether the tenant uses Entra Connect, Entra Cloud Sync, or both.

Confirm the exact sync version before any test is scheduled. Azure AD Connect V1 was retired on 31 August 2022 and is no longer supported, and Microsoft warns that V1 installations may stop working unexpectedly. Ask the client for the installed build of the sync server, the sync feature set in use, the service account the sync engine runs under, and whether any sync server has been left in place after an upgrade. An unsupported or forgotten sync server is a finding in its own right, and it can also change what a tester is allowed to touch in the production tenant.

The hybrid detail belongs here only as scope, not as analysis. For how the tenant-side and on-premises review differ, and why hybrid environments need both reviewed together, see the Active Directory vs Entra ID security assessment comparison, which covers the control plane and sync paths in depth. Agree in the rules of engagement whether the internal test may attempt to move from the synchronized identity into the cloud tenant, and document the decision in writing.

Choosing the approach by environment and situation

When Active Directory is the only directory and no synchronization path reaches a cloud tenant, a configuration-led review of tiering, delegation and privileged group membership usually leads. It answers the question most directory breaches depend on: which accounts can reach domain-level control, and through which chains of group membership, delegated rights and service accounts. An internal penetration test then checks whether those paths are reachable from a standard user's position, which NIST SP 800-115 describes as starting with the access and information of a standard employee and attempting privilege escalation.

Scope to ask for: Tier 0 accounts and groups, delegated rights on domain controllers and OUs, Group Policy write permissions, certificate services and service accounts with privileged rights.
Access to ask for: Read access for the review, plus a standard user account for the internal test, with the rules of engagement agreed in writing.
Evidence to expect: A list of privileged paths with the accounts involved, a remediation order and, where the test ran, the escalation steps reproduced.
Cadence to confirm: CIS Safeguard 18.5 asks for internal penetration tests at least annually, either clear box or opaque box. Confirm with your assessor whether it applies to your program.
Tooling to confirm: Ask whether the provider uses read-only collection that does not change directory objects during the review.

Confirm with your own assessor which test frequency and scope your program needs before you fix the statement of work.

What an Active Directory security assessment delivers versus an internal penetration test

This table compares what each engagement hands back, what access it needs and how its rules of engagement and data handling differ. Read it as a checklist for the written scope: ask each provider for a sample report of each type before you sign. The main takeaway is that a configuration review shows where privilege can flow, while a penetration test shows which of those paths an attacker could actually walk.

Aspect	AD security assessment (configuration review)	Internal penetration test
Primary output	Findings with configuration evidence, such as tier boundaries, delegations and privileged group membership, plus remediation steps	Narrative attack paths, evidence of access gained, retest results and remediation priorities
Starting access	Read-only or low-privilege collection from directory data; no exploitation of production accounts	Standard user account, with escalation attempted toward privileged roles such as domain administrator
Evidence format to request	Per-finding records showing the object, the setting, the value observed and the owner to fix it	Step-by-step path records, screenshots or logs of access gained, and the point where testing stopped
Retest and validation	Re-run of collection after remediation to confirm settings changed	Retest of exploited paths, plus confirmation that detections fired for techniques used (CIS Safeguard 18.4 asks for validation after each test)
Rules of engagement	Agree which accounts, collection tools and hours apply, and whether any write actions are excluded	Agree permitted exploits, lateral movement limits, account lockout thresholds and a stop condition for production impact
Data handling	Confirm where collected directory data is stored, who may read it and when it is destroyed	Confirm handling of credentials, hashes and sensitive files found during escalation, plus secure deletion at close
Priority ranking	Ranked by configuration risk and the number of objects affected, so owners can plan changes	Ranked by demonstrated impact, so the business sees which chains reached sensitive systems
Confirm in the written scope	Report format, sample redacted output, collection method and any items excluded from the review	Report format, sample redacted narrative, testing windows and the named tester or team qualifications

What drives cost and duration for each approach

Both an Active Directory configuration review and an internal penetration test are priced from the same underlying scope: how much of the directory is in play, how much access the team gets, and how often the work repeats. The cards below separate the drivers that set the size of the work from the choices that change the cost of each approach, so you can ask for a quote that is comparable across providers.

Domains, forests and trusts

Each domain, forest and trust relationship adds directory objects, replication paths and delegation boundaries that a configuration review must read and a penetration test may need to traverse. Ask the provider to list every domain and forest in scope, and state whether trusts are reviewed only for configuration or also tested for escalation across the trust boundary. Quotes that do not name them usually understate the work.

Privileged groups and tier model

The number and tier of privileged groups, such as Tier 0 administrative groups, server operators and delegated helpdesk roles, drives how many membership paths and ACLs the reviewer must trace. Microsoft's enterprise access model is the reference for judging whether tiers are separated. Ask whether the quote covers a full path analysis to Domain Admin or a sampled list of groups.

Hybrid sync topology

The sync design between on-premises Active Directory and Entra ID, whether password hash synchronization, pass-through authentication or federation with AD FS, changes what must be reviewed on both sides. Confirm which sync tool is in use, since Entra Connect and Entra Cloud Sync are reviewed differently, and whether a legacy Azure AD Connect V1 installation is still present. Each extra sync path adds review time that recurs as the topology changes.

Access granted to the team

A configuration review usually needs read-only directory and log access, while an internal penetration test needs a standard user foothold and may need a lab or test account. The more access the team is given, the more setup, approval and monitoring work the client carries. Ask the provider to state which accounts, credentials and network segments it will receive, who provisions them, and how they are removed at close.

Production testing

Running escalation attempts against production domain controllers carries more change-control, rollback and scheduling work than testing against a replica or a restored copy. NIST SP 800-115 treats penetration testing with real exploits against production systems as high risk. Ask whether the quote includes a non-production replica, who approves each active step, and what the stop conditions are if a service degrades.

Retest and recurring cycles

Directory configuration drifts as groups, delegations and sync settings change, so a single assessment dates quickly. CIS Controls v8.1 Safeguard 18.5 asks for internal penetration tests at least annually, and Safeguard 18.4 asks for detections to be validated after each test. Ask whether the quote covers one retest of the findings, a repeat of the full review, or a retainer for continuous auditing, and what each one costs to repeat.

Questions buyers ask before commissioning an Active Directory assessment or internal test

What drives the cost of an Active Directory assessment or internal penetration test?

The main drivers are the size and number of domains and forests, how many hybrid components are in scope (for example Entra Connect, AD FS or Entra Cloud Sync), how much access the provider receives, and whether the work is a configuration review, an escalation test, or both. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the scope items, deliverables and assumptions about client-provided access to be listed separately so you can compare quotes on the same basis. Costs are one-time for the assessment itself, while remediation and any retest are separate line items.

How long does an Active Directory assessment take, and what sets the duration?

Duration depends on the number of domains and forests, the depth of the privileged path analysis, the number of hybrid sync paths to review, and how quickly access and answers arrive from your team. An escalation test from a standard user adds time for attack paths that need validation and for safe testing windows agreed with operations. DeployOpen does not publish fixed timelines, so ask for the schedule in the written scope, including the dates each review phase depends on client input.

What access and staff time must we provide for the engagement?

Expect to provide a standard user account for an internal test, read-only directory access or exports for a configuration review, and named contacts from directory, identity and endpoint operations. For hybrid tenants, you also need access to the Entra Connect server configuration and the Entra tenant settings. Staff time is needed for kickoff, access provisioning, answering questions about tiering decisions and reviewing findings. Ask the provider to list each access item, its owner and the approval step in the rules of engagement, which NIST SP 800-115 describes as a template to adapt.

Can our internal team run a configuration review with its own tools?

Yes, an internal team can check tiering, delegation and privileged group membership with its own tooling, and this is useful for continuous auditing. Microsoft's enterprise access model calls for continuous auditing for configuration vulnerabilities that enable inadvertent privilege escalation. The limit is independence and coverage: internal staff often lack a fresh view of attack paths and may not test whether a finding is exploitable. Where an independent assessor is required, NIST SP 800-53 control CA-8 covers independent penetration testing teams, so confirm with your assessor which evidence they accept before choosing an internal approach.

Can a penetration test replace an Active Directory configuration review?

No, not by itself. A penetration test shows which paths an attacker can use from the access it was given, within the time and scope agreed, and it may miss misconfigurations that were not reachable on that day. A configuration review checks the whole tiering model, delegation and privileged paths against the intended design, whether or not an attack succeeds. CIS Controls v8.1 Safeguard 18.5 asks for internal penetration tests at least annually, which is a separate requirement from configuration hygiene. Use the test to validate what the review flags as high risk.

How do an Active Directory assessment and an internal penetration test work together?

Run the configuration review first or in parallel, so the penetration test attacks a known model and can confirm which paths are exploitable. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. After remediation, the test should check that fixes hold and that detections cover the techniques the testers used, which CIS Safeguard 18.4 asks for. Ask the provider to map each finding to its evidence and to the retest it requires.

What should we do about Azure AD Connect V1?

Confirm first whether any server in your environment still runs Azure AD Connect V1. Microsoft Learn states that V1 was retired on 31 August 2022, is no longer supported, and that V1 installations may stop working unexpectedly. Plan the migration to a supported Microsoft Entra Connect version, and review whether Entra Cloud Sync fits your synchronization needs, as Microsoft describes Cloud Sync as the future of synchronization. Include the sync server, its service account and its permissions in the assessment scope, and ask the provider how they will validate the synchronization paths before and after the change.

How DeployOpen scopes, delivers and supports Active Directory testing

DeployOpen approaches Active Directory security assessment vs internal penetration testing as two defined pieces of work inside your own environment, agreed in writing before anything runs. The configuration review and the escalation test can be scoped separately or together, depending on the questions your team needs answered.

How we scope

Engagements are fixed-scope, with the written scope naming domains, forests, tiers and Entra ID tenants covered
The scope states whether the work is a configuration review, an internal escalation test, or both
Rules of engagement set out permitted accounts, test windows, escalation limits and who approves changes
Confirm with your team which privileged paths and synchronization components are in or out of scope

How we build

Review work examines tiering, delegation, group membership and privileged paths against your stated enterprise access model
Escalation testing starts from a standard user account, with the starting access documented before any attempt
Hybrid synchronization paths and Entra Connect configuration are reviewed alongside on-premises directory settings
Each finding is traced to the configuration or path that enabled it, so the fix is specific and testable

How we hand over

Deliverables include a written report separating configuration findings from demonstrated escalation paths
Each finding lists the evidence captured, the affected objects and the change needed to close it
A walkthrough with your directory, identity and security staff covers how to reproduce and verify each fix
Retest scope is agreed in the original written scope, so closure is checked against the same paths

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the original scope
Re-review after directory changes, Entra Connect upgrades or tiering projects can be scoped as follow-on work
Ask any provider, including DeployOpen, to confirm which Entra Connect version and sync method your environment uses

Active Directory security assessment vs internal penetration testing