How to Audit Active Directory Changes
4 min read By Signifium
Knowing who changed what in Active Directory is essential for security and compliance. Whether you’re responding to an incident or meeting audit requirements, Windows can log AD changes—if you enable the right policies and know where to look. This guide walks you through enabling auditing, which events to use, and how to keep AD change history actionable.
Why Audit AD Changes?
- Security — Detect unauthorized moves, deletions, or permission changes.
- Compliance — Many frameworks require evidence of who changed critical directory data.
- Troubleshooting — Correlate user or group issues with recent AD changes.
What Gets Logged?
When Directory Service Changes auditing is enabled, domain controllers log events for:
- Create — New objects (users, groups, OUs, etc.).
- Delete — Object deletions and tombstone behavior.
- Modify — Attribute changes (e.g. group membership, display name).
- Move — Objects moved between OUs.
Key Event IDs
| Event ID | Meaning |
|---|---|
| 5136 | Object created |
| 5137 | Object modified |
| 5139 | Object moved |
| 5141 | Object deleted |
Details (who, when, which attribute, old/new value) appear in the event description and XML.
How to Enable AD Change Auditing
- Group Policy — Edit the Default Domain Controllers Policy (or a GPO linked to the DCs).
- Navigate — Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → DS Access.
- Enable — “Audit Directory Service Changes” (Success and optionally Failure).
- Result — Domain controllers will log 5136, 5137, 5139, 5141 (and related) when changes occur.
Optional: Attribute-Level Detail
For “Value Added” / “Value Deleted” (e.g. group membership), Event ID 4662 can appear if you enable “Audit Directory Service Access” and configure SACLs on the relevant objects. This is more advanced; 5136/5137/5139/5141 are the main ones for change tracking.
Best Practices
- Centralize logs — Use a SIEM or log forwarder so AD change events from all DCs are in one place and retained per policy.
- Alert on sensitive changes — Trigger on schema changes, admin group membership changes, or bulk deletes.
- Retain long enough — Match retention to compliance and incident-response needs (e.g. 90 days to 1 year).
- Least privilege — Limit who can change AD; fewer changes mean easier auditing and fewer false positives.
- Review regularly — Spot-check high-risk OUs or groups so you recognize normal vs. suspicious patterns.
FAQ
What Event IDs should I use for AD object changes?
Use 5136 (create), 5137 (modify), 5139 (move), and 5141 (delete). Enable “Audit Directory Service Changes” in Group Policy on domain controllers.
Do I need to enable anything on each OU?
No. Enabling the policy on the DCs is enough for basic change logging. For 4662 and attribute-level “value added/deleted,” you may need SACLs on specific objects.
How long are AD change events kept?
As long as your Security log retention and any log forwarding/SIEM retention. Increase log size and retention on DCs, and archive to a SIEM for long-term retention.
Can I see the old and new values in the event?
Yes. The event description and XML typically include the attribute name and old/new values for modify operations.
Where can I read more about securing AD and mobile management?
See Why AD Accounts Lock (and How to Fix Them), JEA and Active Directory, and Why MSPs Should Manage Client AD from Mobile.
Auditing AD changes gives you a clear record of who did what and when. Once the right policies are enabled and logs are centralized, you can focus on reviewing and alerting instead of guessing.