Active Directory security assessment

Why an Active Directory security assessment matters before the next audit

An Active Directory security assessment is a review of how your directory is configured and which attack paths that configuration creates, measured against Microsoft's enterprise access model. If a framework, a customer questionnaire, a launch or an insurer asks you to show that directory privilege is controlled, this is the evidence most likely to be requested. It differs from an internal penetration test because it covers configuration as well as exploitable paths: an internal test shows what a tester could reach in a given window, while the assessment checks whether the settings that govern privilege are sound in the first place, including ones no test happened to exploit.

The risks it addresses cluster around a few areas. Privileged groups that have grown beyond their purpose, nested memberships, and accounts that sit outside the tier model can allow privilege escalation through misconfiguration that no one intended. Delegation settings on service and computer accounts, weak or unmonitored certificate services, and Group Policy objects that control privileged systems can each widen the path to domain control. Microsoft Entra Connect also deserves attention as a control plane asset: the server that synchronizes on-premises AD with Microsoft Entra ID can carry trust that reaches into the cloud tenant, so its hardening, its service account and its patch level belong in scope. Microsoft's guidance calls for continuous auditing of configuration that enables inadvertent privilege escalation, which is the discipline this assessment helps you build.

Before the next audit, confirm three things with your assessor or customer: which framework or questionnaire questions on directory privilege you must answer, whether they expect a configuration review, a penetration test or both, and which evidence (tier model documentation, privileged group reviews, certificate services inventory) they will accept. Ask the provider how the assessment maps findings to the enterprise access model tiers and what remediation records it leaves behind. Your own team can start now by listing who holds Tier 0 rights and when those rights were last reviewed, since that list is the first thing a reviewer will test your answers against.

What can be in scope for an AD assessment

Scope in an Active Directory assessment is a set of decisions rather than a list of servers. Each decision below changes what the review examines, who needs to approve it and what access the testers receive, so the rules of engagement should record them in writing before work starts.

Forests, domains and trusts

Start by agreeing which forests, domains and trust relationships fall inside the review. Trusts to partner forests, subsidiaries and acquired domains often carry administrative paths that the owning team does not track. Ask for a current inventory of domain controllers, functional levels and trust directions, and record any domain that is excluded and the reason for excluding it.

Privileged groups and built-in roles

Review membership of the built-in administrative groups, delegated operator groups and any custom group with rights over users, computers or group policy. Nested membership and service accounts that belong to these groups matter more than the direct member list. Agree whether the review covers only membership or also the permissions granted to those groups on domain objects.

Delegation and Kerberos settings

Delegation settings decide which services can act on behalf of users, and Kerberos settings decide how tickets are issued and how accounts with service principal names are protected. Confirm in writing whether the assessor may read account attributes for delegation and encryption types, since these reads are often the basis of the findings. Ask for the list of service accounts with elevated rights so they can be checked against their intended use.

Group Policy objects

Group Policy can set local administrator accounts, logon rights, scripts and software deployment across large parts of the estate. Scope the policy objects by link and by the organizational units they reach, and include the permissions that control who can edit them. Changes to policy are a common route for privilege expansion, so review who can modify the objects as well as what they contain.

Certificate services

Where Active Directory Certificate Services is deployed, the certificate authorities, templates and enrollment permissions can grant identities far more access than they need. Agree whether the review covers the issuing hierarchy, template configuration and enrollment rights, or only the health of the authority. Ask for the list of templates published to users and computers before testing begins.

Tiering model and hybrid sync servers

Compare the actual tier boundaries with the enterprise access model that Microsoft describes, which separates control, management and user planes. Hybrid sync servers such as Microsoft Entra Connect, and the accounts they use, belong to the control plane even though they sit outside the directory itself. Confirm in writing whether these servers are in scope, since they are often administered by a different team.

How the engagement runs, phase by phase

The sequence moves from agreed rules and written approval to a configuration baseline, a comparison against Microsoft's enterprise access model, validated findings, a report and a retest. Each phase closes with a record the client can check, so the final report traces back to evidence.

Document rules and management approval
Before any testing, the engagement lead and the client agree the rules of engagement in writing, following the planning phase described in NIST SP 800-115 and its rules of engagement template in Appendix B. The document names the domains and forests in scope, the domain controllers and certificate authorities that are included, the testing windows, the accounts provided for the review, the contacts for escalation, and the handling of any credential or sensitive data the review touches. Management signs off. The phase is complete when the signed document exists and both sides hold a copy.
Collect directory and configuration data
DeployOpen collects configuration data from the directory using read-oriented access that the client has approved. Typical sources include domain and forest functional levels, privileged group membership, delegation settings, Kerberos configuration, Group Policy objects and their links, certificate services templates and enrollment settings, and trust relationships. Where hybrid identity is in scope, the sync servers and their configuration are included as control plane assets. The phase closes with a dated inventory of what was collected and from which systems, so the client can reproduce the baseline later.
Analyze configuration against the access model
The collected configuration is compared against Microsoft's enterprise access model, which builds on the Active Directory tier model. The analysis asks whether Tier 0 is contained within the control plane, whether the management plane and the data and workload plane are separated within Tier 1, whether Tier 2 user and app access are isolated, and whether a lower plane can control a higher one. It also looks for configuration weaknesses that allow privilege escalation without anyone intending it. The phase closes with a list of candidate findings, each mapped to the tier or plane it affects.
Validate selected findings in controlled checks
Candidate findings are validated where the rules of engagement allow it, using the approach NIST SP 800-115 describes for target vulnerability validation. Validation confirms whether a configuration weakness creates a real path to privileged access in this environment, and it is limited to the checks needed to prove or disprove that path. Changes to production objects are avoided unless the client has approved them in writing. Each validated finding records the evidence, the affected objects and the conditions that made it possible. The phase closes when every candidate is either validated, downgraded or marked as not confirmed.
Report findings with remediation priorities
DeployOpen writes a report that separates confirmed attack paths from configuration observations that deviate from the access model but do not yet form a path. Each item states the affected objects, the evidence, the business context, and a remediation step the client's directory team can carry out. The report also records what was not tested and why, so the reader understands the boundary of the assessment. The phase closes with a read-out meeting, after which the client confirms the report accurately reflects the agreed scope.
Retest remediated items and close
After the client remediates findings, DeployOpen retests the affected items against the same baseline and records whether each fix holds. Retest scope is agreed in writing, and it can be a targeted recheck of specific findings or a repeat of the full configuration review. Confirm with DeployOpen how retests are priced and whether they are included in the original scope. The engagement closes with a retest record that lists each finding as resolved, open or accepted with a named owner.

Which weakness categories the assessment checks

This table lists the Active Directory weakness categories the assessment reviews, what each looks like in a directory, and why it matters to the business. Read it as a checklist of configuration areas that are compared with Microsoft's enterprise access model, not as a list of exploits. Each row describes the category at the level a buyer needs to scope the work.

Weakness category	What it looks like in this directory	Why it matters
Privileged group membership sprawl	Accounts in Domain Admins, Enterprise Admins, Schema Admins or built-in operator groups that are no longer needed, including service and shared accounts with standing privilege	Every extra member widens the set of identities that can change the whole domain, and stale memberships are often invisible to the owning team
Tier 0 exposure from lower tiers	Administrative sessions, management tools or helpdesk accounts that touch domain controllers or identity systems from workstations and servers in lower tiers	Microsoft's enterprise access model expects control of higher planes not to be reachable from lower planes, so a single crossing can compromise the control plane
Delegation misconfiguration	Delegated rights over organizational units, objects or computers granted broadly, or delegation settings on accounts and services that allow impersonation across systems	Delegated permissions are easy to grant and rarely reviewed, so they can quietly give a non-administrative identity administrative reach
Kerberos settings	Encryption types, ticket lifetimes, pre-authentication settings and service account configuration that fall short of current hardening guidance	Kerberos governs how identities prove themselves across the domain, so weak settings affect every authenticated service
Group Policy control over administrative systems	Who can edit policies linked to domain controllers, administrative workstations or privileged server units, and whether those edit rights are tiered	A policy edit can run code or change security settings on many systems at once, so edit rights over those policies carry administrative weight
Certificate template and CA weaknesses	Certificate templates that allow requesters to supply identity details, overly broad enrollment rights, and certification authority administration held by lower-tier accounts	Certificates can be used to authenticate as privileged identities, so a loose template can bypass password and group controls entirely
Sync server exposure	Entra Connect or Cloud Sync servers, and their service accounts, that sit in a lower tier, are poorly monitored or are administered from general-purpose systems	Sync servers hold credentials that bridge on-premises and cloud identity, so they are control plane assets even when they look like infrastructure

Measuring tiering against Microsoft's enterprise access model

The main question in this part of an Active Directory assessment is whether the tier boundaries Microsoft describes exist in your directory, or only on the architecture diagram. Microsoft's enterprise access model builds on the Active Directory tier model. Tier 0 covers the control plane, which includes domain controllers, the identities and groups that can change them, and the systems that manage them. Tier 1 splits into the management plane, where servers and their administrators sit, and the data and workload plane, where business applications run. Tier 2 splits into user access and app access, covering workstations, end users and the applications they use. Each plane should be administered from a separate, protected path, so that an administrator's session in one plane never exposes a higher one.

Microsoft's guidance asks for two ongoing controls. The first is a hierarchy that prevents control of higher planes from lower planes, which is the boundary an assessor tests. The second is continuous auditing for configuration vulnerabilities that enable inadvertent privilege escalation, plus monitoring for anomalies. In practice, the assessment checks whether these boundaries hold. It reviews who is a member of Tier 0 groups, whether Tier 1 administrator accounts sit in Tier 0 groups through nested membership, whether workstations used for administration are isolated from user devices, and whether service accounts, sync servers and delegated permissions cross planes. Where Microsoft Entra Connect runs, the server that synchronizes on-premises directories to the cloud is a control plane asset and belongs in Tier 0. Confirm with your team which identity systems are in scope before the test begins.

Ask the assessor to map each finding to a plane and to state whether the boundary was violated, weakened or undocumented. Decide in advance what evidence you need: exported group membership, the administrative access paths for each tier, and the audit and alerting coverage for changes to Tier 0 objects. A tiering review should end with a short list of boundary breaks ranked by how many paths reach the control plane, along with the owner and date for each fix. Retesting after changes confirms that the boundaries were rebuilt rather than documented around.

What drives the cost and duration of an AD assessment

This table lists the cost components of an Active Directory assessment, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to read a quote line by line and to see which scope facts a provider needs before pricing. The main takeaway is that forest count, privileged group sprawl, and the access model you grant shape effort more than the headline size of the network.

Driver	Why it changes effort	What to ask for in a quote
Forests and domains	Each forest and domain has its own trusts, schema, privileged groups and replication topology to review, so effort grows with each one in scope.	Written list of forests, domains and trusts in scope, and whether child domains are included.
Privileged groups and admin accounts	Nested membership in Tier 0 groups, shadow admins and stale privileged accounts take longer to trace than a flat list suggests.	Count of privileged groups and admin accounts reviewed, and how nested membership is resolved.
Delegated OUs and permissions	Delegated rights on organizational units and ACL inheritance must be checked against the tier model, which is slow to analyze in large directories.	Number of OUs with delegated permissions in scope and whether ACL analysis is included.
Group Policy volume	Each GPO needs review for security settings, script content, link location and delegation, so the GPO count is a direct effort input.	Count of GPOs in scope, and whether settings are reviewed against a stated baseline.
Certificate authorities and templates	Certificate services review covers CA hierarchy, template permissions and enrollment settings, and effort rises with each template and CA.	Number of CAs and certificate templates in scope, and whether CA host hardening is included.
Hybrid sync servers	Entra Connect or Cloud Sync servers are control plane assets, so their configuration, service accounts and sync scope add review work if in scope.	Which sync servers and sync methods are in scope, and whether the Entra tenant is reviewed in the same engagement.
Access model	Read-only collection is quicker to approve but gives less depth, while privileged access needs approval, credential handling and more controls to manage.	Stated access model (read-only or privileged), credentials provided, and who approves access and how it is revoked.
Test depth	A configuration review against the tier model takes less time than an assessment that also validates each attack path, which needs more testing and reporting.	Whether the quote covers configuration review only, validated attack paths, or both, and the methods named.
Retest	A retest is usually a separate, smaller piece of work after remediation, not a re-run of the full assessment, and it is often billed separately.	Whether retest is included, how many rounds, the window it covers, and the evidence required to close findings.

What the client receives and whether it satisfies an auditor

An Active Directory assessment produces a set of linked deliverables rather than one document. Each part answers a different question for the client's CISO, the assessor or the customer reviewing the work, so it helps to know what each section contains and what it can and cannot prove. DeployOpen does not issue audit reports, attestations or certifications; the report is evidence that an independent assessor or certification body may review.

Scope and rules of engagement

This section records the domains, forests, domain controllers, admin tiers and cloud sync servers in scope, along with the test window, contacts, permitted techniques and anything excluded. The rules of engagement follow the structure NIST SP 800-115 describes for the planning phase, where rules are identified and management approval is documented. Check that the document names who authorized the test and what happens if a critical finding appears mid-engagement.

Method and evidence trail

The method section explains which review techniques were used, such as collection and analysis of directory configuration, and which validation steps confirmed exposure. It should separate configuration review from any validated attack path, and state the tools and accounts used. Ask for a record of what was read, when, and under which credentials, so an assessor can reproduce the review under the same conditions.

Findings with severity and affected objects

Each finding should name the affected object, such as a group, GPO, delegation, certificate template or Kerberos setting, with its distinguished name or identifier. The severity rating should explain the reasoning, including whether the finding leads to privileged access. Ask for remediation owners and a note on whether the finding is configuration drift, a design gap or a known exposure, because each needs a different fix.

Tiering gap analysis

The tiering analysis compares the observed environment against Microsoft's enterprise access model, which builds on the Active Directory tier model. It shows where Tier 0 assets are administered from lower-tier systems, where planes are not separated, and where continuous auditing or monitoring is missing. This is the section most useful for a board conversation, because it maps gaps to a target model the client can adopt in stages.

Remediation guidance and retest results

Remediation guidance should give a specific corrective action for each finding, with a note on dependencies that could break services if changed carelessly. The retest section records which findings were closed, which remain open and what evidence closed them. Ask whether the retest is included in the fixed scope or quoted separately, since that affects what the final report can claim.

How the assessment changes by directory architecture

Without a synchronization or federation link, the assessment stays inside the forest and its trusts. Testing centers on domain controllers, privileged groups, delegation, Kerberos settings, Group Policy, certificate services and how the tier model is enforced. Cloud identity is out of scope unless the client adds it to the agreed scope in writing.

Forest and domain scope: confirm which domains, child domains and trusts are included in the agreed scope.
Tier boundaries: check whether Tier 0 accounts and systems are isolated from lower tiers, as Microsoft's enterprise access model describes.
Certificate services: review certificate templates and enrollment settings wherever Active Directory Certificate Services is deployed.
Auditing coverage: confirm whether configuration monitoring and anomaly alerting exist for changes to privileged groups.

Confirm early whether any cloud tenant, sync server or federation server exists, because an overlooked one changes the scope and the cost.

What your team prepares before the assessment starts

Before an Active Directory assessment starts, your team needs to settle access, contacts and change control, because these decide what the assessor can actually read and when. The first decision is the access model: a read-only account with broad directory visibility is usually enough to review privileged group membership, delegation, Kerberos account settings, Group Policy objects and certificate templates, while a privileged account gives deeper checks but must be issued, logged and removed under the written scope. Confirm which option your security team will approve, who issues the account, how its use is logged, and when it expires. Name one technical contact who can answer questions about the forest and domain layout, and one escalation contact who can pause work if a domain controller shows signs of stress.

Next, prepare the lists that the assessment depends on. Provide the members of Domain Admins, Enterprise Admins, Schema Admins and any other groups that hold rights over the directory, along with the service accounts that run sync, backup, monitoring and line-of-business applications. Include the servers that run Microsoft Entra Connect or Cloud Sync, because these are control plane assets and not ordinary member servers. If a tiering design exists, share the written version and the exceptions it allows, since the assessor will compare actual administrative paths against it. If no design exists, say so in the scope, so the findings describe the gap accurately. Agree a change freeze window in which no Group Policy, schema, trust or certificate authority changes are made, so that results reflect a stable state.

Finally, agree in writing who may see sensitive directory data. Account names, password policy details, service account descriptions and attack path diagrams can expose the environment if copied into the wrong place. Decide which staff and which third parties may receive raw exports, whether hashes or credential material will ever be handled (and whether they will be handled at all), where working files are stored, how they are deleted, and who receives the report. These rules belong in the rules of engagement, which *NIST SP 800-115* recommends documenting during planning and management approval. Confirm the detailed storage and retention terms with the provider before the first day of testing.

What to check when choosing an AD assessment provider

A provider's Active Directory work shows in the questions it can answer plainly. The cards below cover the claims you can verify before commissioning an assessment, from tier model experience to how retesting is priced and what the report looks like. Ask for each item in writing so it becomes part of the agreed scope.

Experience with the tier model

Ask how the provider maps your domain against Microsoft's enterprise access model, which builds on the Active Directory tier model. Ask which control plane assets they review, such as domain controllers, AD FS, Entra Connect or Cloud Sync servers, and how they judge whether a higher plane can be controlled from a lower one. A good answer names the specific checks and does not rely on a generic checklist.

Privileged access and data handling

The assessor will hold high-value material: privileged group memberships, service account details and possibly credential material. Ask where collected data is stored, who can read it, how long it is kept, and how it is destroyed at the end. Ask whether the testers use dedicated accounts and workstations, and how they record their own activity for your review.

Sample report structure

Request a redacted sample report before you buy. Check that each finding lists the affected objects, the weakness category, the evidence, the business impact and a remediation step your administrators can act on. A report that only lists severity labels will be hard to use with your auditor or your change board.

Configuration review versus exploit validation

Ask whether the provider reports configuration weaknesses separately from attack paths that were actually demonstrated. A configuration review shows what could be abused across the directory, while validation shows which paths work in your environment. Clear separation lets you prioritize fixes and tells you what was proven rather than inferred.

How retesting is priced

Ask whether a retest of closed findings is included in the fixed price or quoted separately, and how many retest rounds are covered. Ask what happens if a fix changes the attack paths in a way that needs new testing. Confirm the retest deadline in the written scope so the cost is known before the first report arrives.

References under confidentiality

Ask for references from comparable directory environments, and accept that most will be shared under a confidentiality agreement. Ask the reference about scope accuracy, how the provider handled a production concern, and whether the report was usable with their auditor. Verify that the provider has the authority to name the reference before you rely on it.

Questions buyers ask before commissioning an AD assessment

How long does an Active Directory security assessment take?

The sources for this page do not give a duration for this work, so treat any figure you are offered as a quote item, not a fixed rule. Effort grows with the number of domains and forests, the count of privileged groups and delegated organizational units, the volume of Group Policy objects, whether AD CS issues certificates and how many templates it uses, and whether hybrid sync to Microsoft Entra ID is in scope. Ask the provider to split the quote into collection, analysis, validation and reporting, and to state which steps wait on access windows from your team.

What does my team need to provide for an AD assessment?

Before work starts, the planning phase should identify the rules of engagement and record management approval, as described in NIST SP 800-115. In practice, you will need to provide:

A named contact in the identity team and an escalation path to the infrastructure owner
The access level agreed for collection, such as a standard domain account plus any read rights the provider needs on certificate services
Documentation of your tier model, administrative account naming and any known privileged paths
Change freeze dates, backup confirmation and the monitoring team's contact for the test period

The written scope should list which domains, domain controllers, sync servers and certificate authorities are included.

Can our internal security team run an AD assessment themselves?

Internal staff can perform an assessment if they meet the test requirements. PCI DSS requirements 11.4.2 and 11.4.3 allow a qualified internal resource, provided that person has organizational independence from the systems under test. That independence is the difficult part. A team that administers the domain is judging its own configuration, so findings about its own decisions may be softened or missed. Consider whether your staff have current Active Directory and Microsoft Entra expertise, whether they can produce evidence an auditor will accept, and whether a second reviewer outside the administration team can check the results.

Does an AD assessment satisfy PCI DSS or CIS Controls requirements?

It can support those requirements, but it does not satisfy them automatically. PCI DSS requirement 11.4.1 defines internal penetration testing as testing from inside the network, including into the cardholder data environment, and a configuration review is only one input to that work. CIS Safeguard 18.5 asks for internal penetration tests at least annually, and the CIS Controls Assessment Specification describes what those tests should cover. Ask your assessor or framework owner whether the scope, method and reporting meet the requirement before you rely on the output as evidence.

What does a retest of AD findings cover?

A retest checks whether the specific remediations in the report were made and whether they work. Its boundary is the finding list agreed in the original scope, so ask the provider to name each finding and state how it will be verified. Whether a retest is included in the original quote is a commercial term, so confirm it in writing. Also check whether the retest re-runs collection across the whole domain or only the affected objects. PCI DSS requires penetration testing after significant infrastructure changes, so a remediation that changes tiering or delegation may trigger a separate test in addition to the annual one.

Is an Active Directory assessment safe to run in production?

Safety depends on which steps change state, so ask the provider to mark each one. Configuration review is mostly read-only collection, but validating an attack path can involve authentication attempts or changes that affect live accounts. Ask for rules of engagement that define permitted validation, prohibited actions, testing windows, account lockout limits and a rollback plan. Confirm that backups are current and that the security operations team knows the test dates so alerts are not mistaken for an incident. Agree in advance what happens if a domain controller shows unexpected load or a service account fails.

Should an AD assessment be overt or covert?

Most AD assessments are overt, meaning the IT staff know the test is running. NIST SP 800-115 notes that covert testing, done without the IT staff's knowledge but with upper management's permission, shows the damage an adversary could cause rather than finding every weakness. It also states that overt testing is less expensive, carries less risk and is used more often. For configuration review, overt testing usually gives more complete coverage in less time. Covert or assumed-breach work is better suited to testing detection and response, and it belongs in a separately scoped exercise with explicit management approval.

How DeployOpen scopes, tests, reports and retests

DeployOpen is a Chainscore Labs company that runs security testing inside the client's own environment, whether that is their cloud accounts, data centers or an isolated network. For an Active Directory security assessment, that means the domain controllers, the Tier 0 accounts and the certificate and synchronization servers are reviewed where they run, under the client's change control. Every engagement is fixed-scope, and the scope is agreed in writing before any testing starts. The written scope should name the domains and forests in play, whether Microsoft Entra Connect or Entra Cloud Sync servers are included, which privileged groups and delegated OUs are reviewed, whether the work is read-only configuration review, validated attack paths or both, and the accounts and access the testers will receive. Ask the provider to state whether they will use a domain account with read access, a standard user, or an assumed-breach starting point, because that choice changes what the test can prove.

The quote follows from that written scope, not the other way around. Cost is driven by the number of domains and forests, the size of the privileged group population, how many delegation and Group Policy objects need review, whether certificate services are assessed, and how much validation work is expected. Ask the provider to show which parts are one-time (the assessment and report) and which recur (a retest after remediation, or a retainer for continuous configuration checks). DeployOpen does not publish a price list, so ask for a quote tied to a written list of components. Confirm with the provider how findings will be ranked and how the report maps to Microsoft's enterprise access model, since that mapping is what most architecture and governance reviews will ask for.

The report is written for two audiences: the platform team that must fix the configuration, and the security or governance function that must decide what risk to accept. Plan for a retest once remediation is complete, and agree its scope and timing in the original statement of work so that it is not treated as a new engagement. Where continuous checking matters, such as after tiering changes or new certificate templates, a retainer can cover recurring testing. DeployOpen prepares evidence and controls for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence your assessor expects.