What Is Active Directory Auditing? Events and Detections

A domain admin logon at 3 a.m. from a workstation that has never touched a privileged account is either your on-call engineer or an attacker who already owns your network. Active Directory auditing is what turns that event from a line nobody reads into an alert somebody acts on.

Active Directory is the authentication and authorization core of most enterprise networks. Compromise it and an attacker can mint tickets, reset passwords, and reach every domain-joined host. That makes the Security event log on your domain controllers one of the highest-value telemetry sources you own, and most environments either do not collect it or collect so much of it that the signal drowns.

This guide is for the analyst who has to make AD logs useful. It covers what AD auditing is, what to actually audit, the Windows Security event IDs that matter and what each one tells you, how to configure audit policy without flooding the log, how the events flow into a SIEM, and the detections that catch the AD attacks you will see in real intrusions.

What is Active Directory (AD) auditing?

Active Directory auditing is the practice of configuring, collecting, and analyzing the security event records that domain controllers and domain-joined hosts generate when accounts authenticate, when objects change, and when privileges are used. The goal is a reliable trail of who did what, where, and when across the identity layer, so you can detect attacks, investigate incidents, and prove compliance.

Two things produce those records. First, Windows writes events to the Security log on each machine based on the audit policy you set. Second, AD itself records changes to directory objects when you enable directory-service auditing on the domain controllers. AD auditing is the discipline of turning both on deliberately, shipping the output somewhere you can query it, and writing detections against it.

The reason it matters is structural. AD holds the credentials, group memberships, and trust relationships that decide what every user and service can reach. An attacker who lands on a single workstation spends the rest of the intrusion abusing AD: enumerating it, stealing tickets from it, escalating privilege inside it, and using it to move laterally. Almost every step of that leaves a record in the Security log if you are auditing the right subcategories. Turn them off and the most damaging half of an intrusion happens in the dark.

AD auditing is not a product you install. It is audit policy plus log collection plus detection logic, and the quality of each decides whether the trail is usable.

What to audit in Active Directory

Auditing everything is the same as auditing nothing. The log fills with noise, retention shrinks, and the events that matter scroll off before anyone queries them. Pick the activity that an attack actually touches.

• Authentication. Successful and failed logons, Kerberos ticket requests, and account lockouts. This is where credential attacks, password spraying, and ticket abuse show up.
• Account management. Creation, deletion, enabling, disabling, and modification of user and computer accounts. Attackers create accounts for persistence and modify them to weaken security settings.
• Group and privilege changes. Membership changes to security groups, especially privileged ones like Domain Admins, Enterprise Admins, and built-in Administrators. Adding an account to a privileged group is the cheapest privilege escalation an attacker has.
• Directory-service changes. Edits to AD objects and their attributes through DS Access auditing: GPO links, delegation rights, service principal names, and access control lists on sensitive objects.
• Group Policy changes. Modifications to GPOs, which an attacker can weaponize to push code or weaken controls across every machine in scope.
• Replication. Directory replication requests, because the credential-theft technique known as DCSync impersonates a domain controller to pull password hashes through normal replication traffic.

That list maps onto a small set of Windows audit subcategories. Configure those, leave the rest at their defaults, and you get coverage without the flood.

Key Windows Security event IDs to watch

The events live in the Security log on domain controllers and member servers. Account Logon events (the Kerberos ones) and DS Access events appear only on domain controllers, because the DC is the machine doing the authenticating and holding the directory. The table below is the working set worth shipping and alerting on.

A few of these reward close reading rather than a simple count.

Event 4624 carries a Logon Type field that changes what the event means. Type 2 is someone at the keyboard, Type 3 is a network logon, Type 10 is RDP, and Type 9 (NewCredentials) is what runas /netonly and some credential-injection tooling produce. A privileged account showing Type 3 or Type 10 on a host it has no business touching is the lateral-movement pattern worth a rule. Correlate 4624 with 4672 on the same logon ID to confirm the session ran with admin privileges.

Event 4768 got more useful in early 2025. On Windows Server 2016 and later that have taken the January 14, 2025 cumulative update or later, the event was expanded to log the account's supported and available Kerberos encryption types alongside the request. The fields that already mattered still do: a ticket encryption type of 0x17 (RC4) when your domain should be on AES (0x11 or 0x12) is a downgrade worth flagging, and a pre-authentication type of 0 means the account does not require pre-auth, which is exactly the condition AS-REP roasting abuses.

Event 4769 is the one most directly tied to an attack. A single account requesting service tickets for a long list of service principal names, especially with RC4 encryption, is the Kerberoasting signature. The attacker is harvesting tickets to crack service-account passwords offline. Because 4769 fires on every normal service-ticket request too, the detection is about anomalous volume and encryption type, not the event's mere presence.

How to configure AD audit policy without drowning

Windows gives you two audit systems, and mixing them breaks both. The legacy Basic audit policy under Local Policies has nine broad categories. The newer Advanced Audit Policy Configuration, under Security Settings, splits the same ground into ten categories and roughly sixty granular subcategories. Microsoft's guidance is to use the advanced settings and to not combine them with the basic ones on the same machine, because the two can conflict and produce unpredictable results. For a domain, you push the advanced policy through a Group Policy Object linked at the domain-controllers OU and, separately, at the rest of the estate.

The ten advanced categories are Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use, System, and Global Object Access Auditing. You do not enable all of them. The high-value subcategories for AD auditing are:

• Account Logon > Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations (4768, 4769, 4771). DC-only.
• Account Logon > Audit Credential Validation (4776 for NTLM). DC-only for domain accounts.
• Logon/Logoff > Audit Logon (4624, 4625) and Audit Special Logon (4672).
• Account Management > Audit User Account Management (4720, 4722, 4725, 4726, 4738) and Audit Security Group Management (4728, 4732, 4756).
• DS Access > Audit Directory Service Changes (5136) and Audit Directory Service Access (4662). DC-only.
• Policy Change > Audit Audit Policy Change, so an attacker who disables your auditing leaves a mark.

Two settings stop the flood. Set most subcategories to log Success and Failure deliberately rather than blanket-enabling both everywhere; failed object access in particular generates enormous volume. And size the Security log generously on domain controllers (commonly several gigabytes) so events survive long enough to ship, because a busy DC can roll a default-sized log in minutes. The point of restraint is retention: the cheapest way to lose an investigation is to overwrite the evidence before you collected it.

Object-level auditing has one extra step. Event 4662 and 5136 only fire for objects whose system access control list (SACL) requests auditing. To catch DCSync you configure a SACL on the domain object that audits the replication extended rights. Without the SACL, the subcategory is on but the object stays silent.

How AD logs feed a SIEM

A single domain controller's Security log is unreadable at human scale and useless for correlation if it stays on the box. AD auditing only pays off when the events leave the DC and land in a SIEM where you can query across hosts and over time.

The pipeline has four stages.

• Collect. Forward the Security log off each domain controller and member server. Windows Event Forwarding (WEF) is the native, agentless option; most SIEMs also ship an agent (Splunk Universal Forwarder, Elastic Winlogbeat, the Microsoft Sentinel AMA) that does the same job with more control.
• Normalize. Parse the raw event into fields: account name, logon type, source host, ticket encryption type, target group. Normalization is what lets one rule match the same behavior whether it came from a DC or a workstation.
• Correlate. Stitch related events into a story. A 4624 plus 4672 on one logon ID is a privileged session. A burst of 4625s followed by one 4624 is a brute force that finally worked. Correlation across hosts is the entire reason the logs leave the DC.
• Alert and retain. Fire detections on the patterns that matter and keep the raw events long enough to investigate. Identity attacks are often found weeks after the fact, so retention is part of the detection, not an afterthought.

Volume is the constant pressure. A large domain produces millions of 4624 and 4769 events a day, almost all benign. Filter aggressively at the source (drop machine-account network logons you have baselined as normal), normalize so detections are cheap to run, and reserve alerting for deviations from a known-good baseline rather than the raw presence of an event. The SIEM is where AD auditing becomes detection engineering instead of log hoarding.

Detecting common AD attacks with audit logs

The events earn their keep when they catch a real technique. Each of the following maps to events in the table above, and each has a benign twin, so the detection is about context and volume, not a single log line.

• Password spraying and brute force. Many 4625 (or 4771 on the DC) failures spread across many accounts from one source, often followed by a single 4624 success. The spread across accounts, not the count against one account, distinguishes spraying from a forgotten password. The MITRE ATT&CK technique is T1110.
• Kerberoasting. A spike in 4769 service-ticket requests for many distinct SPNs from one account, especially with RC4 (0x17) encryption. The attacker is collecting service tickets to crack offline (T1558.003). Baseline normal per-account SPN request volume and alert on the outliers.
• AS-REP roasting. 4768 requests where the pre-authentication type is 0, meaning the target account does not require Kerberos pre-auth. An attacker enumerates those accounts to request roastable tickets (T1558.004). The accounts with pre-auth disabled should be a short, known list.
• Golden and silver tickets. Forged Kerberos tickets often show service-ticket use (4769) without a preceding TGT request (4768) for the same account, or tickets with anomalous lifetimes and encryption. The mismatch between expected ticket lifecycle events is the tell (T1558.001, T1558.002).
• DCSync. A 4662 event showing replication extended rights (the Directory Service replication GUIDs) requested by an account that is not a domain controller. Legitimate replication comes from DCs; anything else pulling password data over replication is credential theft (T1003.006). This requires the SACL on the domain object described above.
• Privilege escalation via group changes. A 4728, 4732, or 4756 adding an account to Domain Admins, Enterprise Admins, or a local Administrators group, especially outside a change window or from an unexpected source. This is the cleanest single-event escalation signal you have.
• Persistence via account changes. A 4720 creating an account on a domain controller, or a 4738 setting password-never-expires or trusted-for-delegation on an existing account. Attackers prefer modifying a legitimate account over creating an obvious new one.
• Lateral movement. Privileged 4624 Type 3 or Type 10 logons to hosts the account does not normally touch, correlated with 4672. Tools like PsExec leave a predictable trail of network logons and service creation. This is the lateral movement phase, and AD authentication events are its primary witness.

One more reason to audit Kerberos and NTLM separately: the authentication protocol in use is itself a signal. A sudden rise in NTLM authentication (4776) in an environment that should be Kerberos-first can indicate relay attacks or tooling that forces the weaker protocol. The distinction between the two protocols, and why attackers prefer the older one, is covered in NTLM vs Kerberos.

The bottom line

Active Directory auditing is audit policy, log collection, and detection logic working together to make the identity layer observable. Configure the right subcategories so the events you need exist, ship them off the domain controllers into a SIEM so you can correlate across hosts and time, and write detections against the patterns that real techniques produce: spraying in 4625 bursts, Kerberoasting in 4769 spikes, DCSync in 4662, privilege escalation in 4728.

The discipline is in the restraint. Auditing everything buries the four or five events that would have caught the intrusion, so collect deliberately, baseline what normal looks like in your environment, and alert on the deviation.