A common sign is that permission changes occur but no corresponding Security event appears, especially Event ID 5136 for directory service changes. If auditing is enabled but change records are missing, the policy scope, SACL, or success and failure settings may be incorrect. That leaves teams blind to administrative changes on sensitive objects.
Why Missing Audit Events Are the First Warning Sign
When active directory permission auditing is working, a permission change on a sensitive object should leave a trace that can be correlated to the actor, target, and time of change. If administrators can make changes but no corresponding security event appears, the problem is usually in the auditing configuration, not the directory itself. That gap matters because it removes the evidence needed to distinguish approved administration from silent privilege drift.
A healthy audit path should capture changes to directory objects, policy-linked settings, and other high-value operations in a way that is reviewable after the fact. If the change happened but the record did not, the control is not doing its job. In practice, the most useful signal is not “some logs exist,” but “the right change produced the expected event every time.”
How to Recognise Broken Coverage, Not Just Broken Logging
The common failure pattern is partial coverage. For example, a team may have auditing enabled at the domain level yet still miss changes on specific OUs, privileged groups, or other sensitive objects because the SACL is absent or too narrow. That creates false confidence: the environment appears monitored, but the objects that matter most are not actually producing records.
Another sign is inconsistency. Some changes generate events while similar changes do not, or only a subset of domain controllers shows the activity. That often points to uneven policy application, replication lag in the audit configuration, or a mismatch between where the change is made and where the audit setting is enforced. If the pattern is intermittent, treat it as a configuration defect until proven otherwise.
Missing or unexpected security events also become visible when organisations rely on reviews to catch privilege changes after the fact. If permission assignments, group membership changes, or delegation updates are not appearing in the expected event stream, the review process is blind even if the directory state itself is correct. This is why audit validation should be tied to real change tests, not just a policy checklist.
What Should Be Verified Before Trusting the Audit Trail
Event ID 5136 is a useful reference point because it is associated with directory service changes, but the broader question is whether the audit policy, SACL, and success or failure settings are aligned to the objects you care about. If auditing is turned on yet change records are missing, verify the scope at the object level, not only at the policy level. In many environments, the defect is one layer below where people are looking.
It also helps to verify that the audit path covers both administrative and delegated change paths. Changes made through scripts, identity tools, or delegated admin roles should still produce the same traceability as changes made through direct console access. If one path leaves records and another does not, the control is inconsistent and should not be treated as reliable evidence of who changed what.
- Test a known permission change on a non-production sensitive object and confirm the expected event appears.
- Compare object-level SACLs against the classes of changes you actually need to detect.
- Check whether all relevant domain controllers and management paths emit the same audit evidence.
Risk and Threat Considerations
Broken permission auditing creates a detection gap that can hide administrative misuse, privilege creep, and stealthy post-compromise changes. The risk is not only missed alerts, but also the inability to prove whether a sensitive change was authorised, which weakens incident response and forensic reconstruction.
Failure mechanism: The audit policy is enabled in principle, but the object-level SACL, success and failure settings, or scope are incomplete, so the change never generates the expected directory event.
Impact: Teams lose visibility into sensitive permission changes, cannot reliably validate admin activity, and may leave excessive access in place longer than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Directory change auditing depends on defining the events that must be captured. |
| AU-12 — Audit Record Generation | Missing event 5136 records indicates audit generation is not working as intended. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit coverage is only useful if changes are reviewable and anomalies are investigated. | |
| Recommendation — Define required AD change events and verify they are logged for sensitive objects. Enable generation of the directory change records you expect to review. Review AD audit records for missing or inconsistent permission-change evidence. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | AD permission auditing is a logging control that must capture relevant security events. |
| A.8.16 — Monitoring activities | Broken auditing becomes visible when monitoring fails to surface expected change events. | |
| Recommendation — Configure logging to record sensitive AD permission changes and verify coverage. Monitor AD change activity for gaps between permission changes and recorded events. | ||
Practitioner Guidance
What to verify: Treat missing audit events as a control failure until you can reproduce a change, observe the expected event, and trace it back to the exact object and policy scope. If you cannot do that on a sensitive object, the audit trail is not trustworthy for operational decisions.
What good looks like: A deliberate permission change on a protected OU, group, or delegated admin object should create the expected security record every time, regardless of whether the change was made interactively or through an administrative workflow.
Practitioner takeaway: The key judgement is not whether auditing is enabled, but whether it is provably catching the changes that matter most on the objects that matter most.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- What are the signs that directory sync is not working correctly in an application?
- What are the signs that Azure Active Directory security monitoring is not working as intended?
- What are the signs that Active Directory recovery controls are not working well enough?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
