Active Directory Auditing: The Events to Track and How Long to Keep Them

Active Directory auditing is the practice of recording and reviewing changes and sign-in activity in your directory, so you can show who did what to which account, group or policy, and when. Windows can generate most of that record on its own, but only if the right policies are switched on, and the default experience leaves real gaps. This guide covers which events matter, how to turn them on, how long to keep them, and where native auditing runs out.

Why Active Directory is worth auditing closely

Active Directory decides who can reach almost everything else on a Windows network. Add someone to a privileged group and they inherit that group’s reach across the domain. That makes a small directory change one of the most consequential events in the environment, and also one of the easiest to miss among millions of routine logons.

Compliance frameworks care for the same reason. PCI DSS 10.2.1.5 requires logs to capture changes to identification and authentication credentials, including creating accounts, elevating privileges, and any change to accounts with administrative access. NIST SP 800-171 Rev. 3 and the HIPAA Security Rule both expect activity to be recorded and reviewed. For most Windows shops, the directory is where a good part of that evidence comes from.

Which Active Directory events to audit

You do not need every event Windows can produce. These are the ones that answer the questions an investigator or auditor actually asks. Names are Microsoft’s own.

Event descriptions come from Microsoft’s security auditing documentation.

How to turn on Active Directory auditing

Auditing is controlled through Group Policy, and domain controllers are where most of these events are written. Use the Advanced Audit Policy Configuration settings, which give finer control than the older basic categories, and apply them to the Domain Controllers organizational unit through a dedicated policy.

The subcategories to look at first are:

• Audit User Account Management, for account creation, changes, resets and lockouts.
• Audit Security Group Management, for group membership and group changes.
• Audit Directory Service Changes, for attribute-level changes such as event 5136.
• Audit Logon and Audit Special Logon, for sign-ins and privileged logons.
• Audit Audit Policy Change, so changes to the auditing itself are recorded.

One step catches people out. Per Microsoft’s documentation, Directory Service Changes events are generated only for objects with configured system access control lists (SACLs), and only when access matches those settings. Turning the policy on is not enough. If the SACL on the objects you care about does not cover the change, nothing gets written, and you will not know until you go looking for the record.

After that, test it. Add a test account to a test group, then confirm that the event appears on the domain controller that handled the change.

How long to keep Active Directory audit logs

Retention requirements differ by framework, and some of the most common assumptions are wrong.

• PCI DSS v4.0.1, Requirement 10.5.1: at least 12 months of audit log history, with the most recent three months immediately available for analysis.
• NIST SP 800-171 Rev. 3, 03.03.03: keep audit records for a period consistent with your records retention policy. No fixed number is given, so your policy has to set one.
• HIPAA: 45 CFR 164.312(b) requires audit controls without stating a log retention period. Separately, 45 CFR 164.316(b)(2)(i) requires required documentation to be kept for six years, and many organizations apply that to activity records as a precaution. Ask your counsel how it applies to you.

Whatever the answer, a local Windows Security log cannot meet it by itself. It is a size-limited file on each domain controller, and on a busy controller older events get overwritten as new ones arrive. Retention in practice means forwarding events somewhere else.

Where native Active Directory auditing runs out

Native auditing generates useful records, and its limits are mostly about what happens afterward:

• Events are scattered. Each domain controller keeps its own log, so following one change can mean checking several servers.
• The records are hard to read. Answering “who added this person to Domain Admins last March” means knowing the event ID, the server and the fields to interpret.
• Administrators can reach the evidence. A domain administrator can clear a log on a domain controller. Event 1102 records that it happened, but the cleared events are gone unless they were forwarded first. That matters for PCI DSS 10.3.2 and NIST 03.03.08, which both require protecting logs from modification.
• Nothing maps events to controls. Windows records activity, and it is up to you to turn that into a statement an auditor can test.
• Active Directory is no longer the whole identity picture. Sign-ins and changes in Microsoft Entra ID do not appear in the domain controller’s Security log. Microsoft also limits Entra audit and sign-in log retention to seven days on the free tier and 30 days on P1 and P2, so that data needs to be exported to last through an audit period. We cover the hybrid side in monitoring identity across Active Directory and Microsoft Entra ID.

An Active Directory audit checklist

If you are preparing for a review, these are the checks that find the most problems:

• Advanced audit policy is applied to all domain controllers, confirmed on each one rather than assumed from the policy.
• SACLs cover the objects behind your Directory Service Changes auditing.
• Security logs are forwarded off the domain controllers to a separately administered store.
• Your retention period is written down and meets your framework’s requirement.
• Membership of Domain Admins, Enterprise Admins and other privileged groups has been reviewed, with a named approver and a date.
• Alerts exist for privileged group changes, audit policy changes and cleared logs.
• Inactive accounts have been identified and disabled.
• Service accounts have named owners, and any interactive use of them is explained.
• You have tested retrieving a specific change from at least six months ago.

Privileged groups usually draw the most scrutiny, and our guide to the privileged access management audit covers what auditors ask for there.

Common questions about Active Directory auditing

What is Active Directory auditing?

Active Directory auditing is the recording and review of activity in the directory, including account changes, group membership changes, policy changes and sign-ins. It lets you determine who made a change and when, and gives you evidence to support security investigations and compliance audits.

Is Active Directory auditing enabled by default?

Do not assume it covers what you need. Windows has default audit settings, but the coverage varies by version and policy, and attribute-level directory change auditing also depends on SACLs. Check the effective audit policy on each domain controller and test that the events you depend on actually appear.

Which event ID shows a user was added to a group?

Event 4728 records a member added to a security-enabled global group, 4732 to a local group, and 4756 to a universal group. These are generated under the Audit Security Group Management subcategory and are worth alerting on for privileged groups.

How can you tell who deleted an account in Active Directory?

Look for event 4726 on the domain controller that processed the change. It records the deleted account and the account that performed the deletion. If the log has already been overwritten, you need a forwarded copy, which is one reason to send events off the domain controller.

From events to evidence

LT AuditorMP® gives you centralized visibility into Active Directory, Microsoft Entra ID and Windows logon events from a single platform. It tracks user and group changes, uncovers excessive permissions, and exports reporting mapped to frameworks including NIST, HIPAA, PCI DSS and ISO 27001. See how it works on the platform page.

Request a demo to see your own directory activity in one place.