Audit Active Directory Security: What to Review First and How to Prove Remediation

To audit active directory security well, start with evidence instead of a generic checklist. A defensible Active Directory audit should tell you which identities can control the directory, which permissions can replicate secrets or rewrite trust boundaries, which protocol or certificate settings still create short attack paths, and which proof you will keep so remediation can be verified later.

This guide stays focused on on-prem Active Directory. If your operators, privileged roles, or recovery workflows also depend on Microsoft Entra, run this review alongside a separate Entra assessment instead of blending both scopes into one vague report. The goal here is narrower: show what an AD security audit must cover first, which findings deserve early remediation, and how to prove that a fix actually changed the control plane.

A practical AD audit should produce five outputs:

1. a scoped inventory of the directory surfaces that matter
2. a list of identities and permissions that can control privileged assets or replicate secrets
3. a shorter list of attack paths that deserve immediate remediation
4. evidence that hardening controls are really enforced in production
5. a validation pack you can compare in the next review cycle

What Does It Mean to Audit Active Directory Security?

An Active Directory audit is not just a password policy check and it is not a one-time health report. It is an evidence-driven review of the identities, permissions, services, policies, and telemetry that define who can control the directory and how quickly that control could be abused.

That means the audit output should answer concrete questions:

• Which users, groups, service accounts, or computers have domain-wide or near-domain-wide control?
• Which rights can replicate sensitive directory data or rewrite trust boundaries?
• Which protocol and delegation settings reduce attack cost for an adversary?
• Which findings are only configuration drift, and which ones create direct escalation paths?
• Which exports, logs, and state snapshots prove a fix is real?

If the review cannot answer those questions, it is still a checklist, not an audit. That distinction matters because the same environment can look acceptable in a policy spreadsheet while still exposing short paths to Domain Admin through replication rights, delegation, stale privileged accounts, or certificate abuse.

Define the Audit Scope Before You Review Findings

The fastest way to waste time is to start reviewing findings before defining scope.

Mandatory scope decisions

Decide first which directory surfaces are actually in play:

• the domain or forest being reviewed
• domain controllers and privileged admin groups
• delegated administration groups and high-impact service accounts
• replication rights, ACL-sensitive objects, and inheritance boundaries
• Kerberos delegation and service principal exposure
• Group Policy, LDAP posture, Windows LAPS, and audit policy
• AD CS, but only if it exists in the forest

Keep the scope honest. If AD CS is not deployed, say it is out of scope and move on. If a separate PKI team owns it but AD CS still exists in the forest, it belongs in the audit because certificate issuance can still change privileged exposure. The same rule applies to hybrid identity: if Microsoft Entra affects privileged operators, recovery paths, or app administration, note the dependency, but do not pretend an Entra review replaces an AD review.

Evidence requirements before the first export

This is also the point where you decide what proof will be retained between cycles. If the audit will later need to prove that a privileged group was cleaned up or a dangerous right was removed, capture that requirement before the first export is taken.

Review Privileged Access and Tier 0 First

Start with the directory control plane, often described operationally as Tier 0. That means reviewing the identities and administration paths that can directly change the domain, domain controllers, trust boundaries, or the objects that protect them.

What to review on the first pass

Review at least:

• built-in and custom privileged groups
• delegated admin groups and nested group paths
• stale privileged accounts and old exception accounts
• privileged service accounts that still have standing access
• administrative separation between normal user identities and admin identities

This is the right starting point because poor administrative practice and weak segmentation are exactly where real AD compromises take hold. The 2023 ANSSI guidance on administering AD-backed systems explicitly states that AD compromises result from poor administration practices and insufficient segmentation, then describes how attackers use lateral movement and privilege escalation to gain full control of the directory.

What the privileged-access section should prove

The practical test is simple: can you explain who can administer the directory, from where, with which account type, and why that access still exists? If not, the audit should stop here first. A directory with clean password policy but weak privileged access design is still a weak directory.

For related drift patterns, use Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits and Stale Privileged Accounts: Hidden Risk in Active Directory as supporting reviews.

Audit Replication Rights, ACL Abuse, and Short Attack Paths

After privileged groups, review the permissions that can silently bypass them. A serious AD audit must include principals with secret replication capability and broad control over sensitive objects.

Rights that deserve immediate review

Microsoft documents DS-Replication-Get-Changes-All as a control access right that allows the replication of secret domain data. That is enough to make replication rights a first-class audit item, not an advanced edge case. If you do not know exactly which principals hold replication-related rights, the audit is incomplete.

The same applies to object control. You are not only looking for obvious admin membership. You are looking for write, permission-management, or ownership paths on high-value objects such as:

• the domain root
• privileged groups
• AdminSDHolder
• OUs that host sensitive admins, servers, or GPOs
• GPO-linked containers that can change security posture at scale

Which telemetry helps validate changes

Logging matters here, but it must be described precisely. Event 5136 is generated when a directory service object is modified, but only when the object has the relevant SACL entry. Event 4662 records operations performed on an AD object, but again only when the appropriate SACL exists and the operation matches it. Neither event is a magical detector. They are evidence points you can use to validate high-value changes and monitor specific objects after you scope the audit correctly.

This is why attack-path thinking matters. The question is not only whether a right exists. The question is whether that right creates a short path to directory control. For a deeper path review, pair the audit with ACL Abuse and DCSync: The Silent Paths to Domain Admin and Active Directory Attack Paths to Domain Admin.

Review Kerberos, Delegation, and Service Account Exposure

Kerberos remains central to AD exposure, especially through service accounts and delegation settings.

Accounts and settings to review first

At minimum, review:

• user or service accounts with SPNs
• privileged accounts that also expose SPNs
• unconstrained delegation
• constrained delegation and resource-based constrained delegation where used
• service accounts that have no clear owner, no recent review, or excessive privilege

Why service-account exposure belongs in the core audit

SPN-bearing accounts belong in scope because Kerberoasting depends on service tickets requested for SPNs, which is why MITRE ATT&CK T1558.003 is still useful detection context for a technical audit. You do not need an exploit walkthrough in the audit. You do need to know which service accounts expose offline cracking opportunity and whether any of them are also privileged.

Delegation needs the same level of precision. Microsoft describes constrained delegation as a safer form of delegation than unconstrained delegation because it restricts the services to which a server can act on behalf of a user. That does not make constrained delegation automatically safe. It means it should be reviewed in context: which front-end services are allowed, which back-end services trust them, and whether the business need still exists.

If you want the delegation-specific deep dive, use Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. In the audit itself, keep the focus on ownership, privilege, and reachable abuse paths.

Include AD CS If It Exists in the Forest

If Active Directory Certificate Services is deployed anywhere in the forest, include it. Microsoft documents AD CS as a Windows Server role for issuing and managing PKI certificates used in secure communication and authentication protocols. That alone is enough to treat it as identity infrastructure, not as a side topic for a future PKI review.

What the AD CS portion should cover

A practical AD audit should therefore review:

• enterprise CAs that issue authentication-relevant certificates
• published certificate templates
• who can enroll and who can modify template permissions
• whether certificate issuance expands privileged exposure
• whether certificate paths create escalation routes that bypass the hard work already done on groups and delegation

Do not assume every AD environment has AD CS. But if it does, do not leave it out of the audit. Certificate issuance and template permissions can materially change who can authenticate and as whom. For the certificate-specific technical breakdown, see ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

Check GPO, LDAP, LAPS, and Logging Controls

Once privileged paths and escalation mechanics are understood, review the controls that are supposed to harden the estate and generate the telemetry you rely on.

Controls to validate directly

For LDAP, Microsoft states that LDAP signing cryptographically signs LDAP communications to verify authenticity and integrity, while channel binding ties application-layer security to the underlying TLS session. In practice, the audit should confirm the effective domain controller policy, not just the intended standard. This matters even more now because Microsoft documents version boundaries clearly: new Windows Server 2025 Active Directory deployments require LDAP signing by default, but upgraded environments preserve existing policy. That means you should audit effective posture, not assume the default. For configuration and validation details, use LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

For Windows LAPS, Microsoft documents that the feature automatically manages and backs up local administrator passwords and can also back up the DSRM password for Active Directory domain controllers. An AD audit should therefore check not only whether LAPS is present, but whether the intended devices are covered, where passwords are backed up, who can read them, and whether DSRM protection is configured where required. For the operational gap review, see Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

Logging that proves control changes

For logging, keep the guidance exact:

• Audit Security Group Management covers changes such as group creation, deletion, and member add or remove events.
• Event 5136 helps validate object modifications when the right SACL exists.
• Event 4662 helps monitor operations on sensitive AD objects when directory service access auditing and SACLs are configured.

Microsoft also states that advanced audit policy settings can be managed through Group Policy so organizations can modify, test, and deploy more granular auditing to the users and groups that matter. That is the correct operational posture: test the policy, confirm event volume and retention, and verify that the team actually reviews the resulting evidence. For the event set that matters most after deployment, use Active Directory Monitoring: Security Event IDs That Matter.

Evidence to Keep Between Audit Cycles

A useful AD audit leaves behind a reusable evidence pack, not just a slide deck.

Minimum evidence pack

Keep date, scope, source, and owner with every artifact. If the next audit cannot compare like-for-like exports, the team will spend time arguing about whether a finding is new instead of proving whether a path is gone.

Prioritize Remediation by Identity Impact

Do not remediate in a flat queue. Start with what most directly changes an attacker's reach.

Fixes that usually belong first

First-priority fixes usually include:

• replication-related rights that can expose secret domain data
• ACL or inheritance paths that create short routes to privileged objects
• unconstrained delegation and highly exposed privileged service accounts
• AD CS misconfigurations that create authentication or enrollment abuse paths

Controls that strengthen the next review cycle

Next come controls that reduce attacker freedom and improve future validation:

• LDAP signing and channel binding posture
• Windows LAPS coverage and privileged password hygiene
• audit-policy gaps that leave high-value objects effectively unmonitored

Only after those should you spend effort on cleanup items that improve governance but do not materially shorten an attack path on their own. This is also why a repeatable review matters more than a static report. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works covers the operating model, while Active Directory Security Audit Tools: What to Compare Before You Choose covers the tooling question.

Validation After Remediation

A finding is not closed because a ticket says it is closed. Validate from the same control surface that exposed the issue.

After a privileged-access cleanup, rerun group and delegated-admin exports and confirm the identity no longer holds the effective path. After a replication-rights cleanup, confirm the principal no longer appears in the replication review set. After LDAP hardening, verify the effective policy and validate that unsigned binds are rejected as expected. After a Windows LAPS rollout, confirm policy application and password backup state on the intended population. After an AD CS fix, verify that the risky template, enrollment scope, or permission path is actually gone.

What a closed finding should include

Telemetry should be validated too. If you expect future changes on sensitive objects to produce 5136 or 4662 evidence, prove that the audit policy and SACL model actually generate the events you intend to rely on. If group changes are important, prove the relevant group-management events are present in the logging path and retained long enough to be useful.

The final closure pack should include:

• the before and after state
• the change owner
• the validation method
• the remaining exception, if any
• the date the finding will be rechecked

That is what turns an AD audit into a repeatable control rather than a document that ages out the moment the next delegation change lands.

How EtcSec Helps Structure a Repeatable AD Audit

EtcSec should sit inside this workflow, not replace it with marketing language. The useful part is repeatability.

Where the product fits and where it does not

A repeatable AD audit needs the same checks rerun against the same control surfaces so you can tell whether a privileged path is new, unchanged, or actually remediated. EtcSec helps structure that by keeping the review anchored on concrete findings such as EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED, and LAPS_NOT_DEPLOYED.

The current deployment model also supports local collection rather than forcing the audit to start as a SaaS exercise. That matters operationally because AD evidence is better when the collection path is stable, the same checks are remeasured after remediation, and the outputs can be retained between cycles.

The practical value is therefore narrow and testable: structure the audit, keep the finding set measurable, and make reruns easier to defend. If your question is tool selection rather than audit method, use Active Directory Security Audit Tools: What to Compare Before You Choose.

Primary References

• Audit Security Group Management
• 5136(S): A directory service object was modified
• 4662(S, F): An operation was performed on an object
• DS-Replication-Get-Changes-All extended right
• LDAP signing for Active Directory Domain Services
• Manage LDAP signing using Group Policy for Active Directory Domain Service
• What is Windows LAPS?
• Kerberos Constrained Delegation Overview in Windows Server
• What is Active Directory Certificate Services?
• Advanced Audit Policy Configuration
• Audit Active Directory objects in Windows Server 2003
• Recommandations pour l’administration sécurisée des SI reposant sur AD
• MITRE ATT&CK T1558.003: Kerberoasting