Active Directory Logging — What to Collect, What to Watch, What to Alert On Which Active Directory Event IDs to collect, the auditpol commands that enable them, and five alert rules for brute force, password spray and Kerberoasting.
Most domain controllers running in production right now still carry whatever audit configuration Windows shipped with at install time. Nobody went back to it. That holds up fine until something actually happens — an executive's account is used at three in the morning, or a new user appears in Domain Admins with no request ticket behind it — and the investigation stalls, because the events that would have answered the question were never written in the first place.
Why AD logs matter
In September 2024 six cyber agencies across five countries — Australia's ACSC, together with NSA and CISA in the US, the Canadian Centre for Cyber Security, New Zealand's NCSC and the UK's NCSC — published a joint guide, Detecting and Mitigating Active Directory Compromises , which catalogs the 17 most common techniques used against AD. The guide's framing: attackers go after Active Directory as a matter of routine, to escalate privileges and reach the most sensitive objects an organization holds.
The reason is structural. AD keeps the accounts, the privileges and the policy for every machine in the domain in one place. One Domain Admin credential unlocks every machine, which is why enterprise-wide ransomware has to get through AD before it can spread.
The other half of this is legal. Section 26 of Thailand's Computer Crime Act (B.E. 2550, amended B.E. 2560) requires service providers to retain computer traffic data for at least 90 days, and whether AD logon/logoff records belong in what must be kept depends on the provider type under annex B of the 2021 notification (the Computer Crime Act log retention guide covers the requirement in detail). But 90 days is the compliance floor, not an investigation window.
Event IDs to collect
The tables below follow the Windows audit categories, because each group maps to exactly one auditpol line in the "Getting AD logs into a SIEM" section further down. Skip a category and nothing in that group gets written at all.
The "meaning" column carries Microsoft's own event titles, so you can search on them directly.
Logon/Logoff — who signed in where, and when
Event ID Meaning Importance Read it with 4624 An account was successfully logged on High Logon Type — 2 = interactive at the console, 3 = network, 10 = RemoteInteractive (RDP) 4625 An account failed to log on Very high Status / Sub Status code 4634 An account was logged off (session ended) Medium Pairs with 4647 (user-initiated logoff); you normally see both 4648 A logon was attempted using explicit credentials Medium Baseline it before you alert on it 4672 Special privileges assigned to new logon High, with conditions Subject\Security ID
Three things the table on its own does not tell you, and each one is a reason detection rules built on these events misfire.
4624 does not always carry an IP. Microsoft states directly that the IP address/port and workstation name fields are populated depending on the authentication context and protocol in use — network logons over Kerberos frequently have no workstation name, and NTLM logons frequently have no TCP/IP detail. Anyone writing a rule that counts events "from the same IP" needs to know that before they write it.
Plenty of reference material labels 4634 a "successful logoff", which is a misreading — there is no failure variant. The event means one thing: a logon session was terminated and no longer exists.
4672 is far noisier than its name suggests. It fires at logon whenever a new session picks up any of 13 sensitive privileges (SeDebugPrivilege, SeTcbPrivilege, SeBackupPrivilege and so on), and Microsoft's own documentation warns you will see a lot of them, because every SYSTEM logon triggers one. Microsoft's guidance is to alert only where Subject\Security ID is something other than LOCAL SYSTEM, NETWORK SERVICE or LOCAL SERVICE. Deploy it raw and unfiltered and your team will mute the rule inside a week.
Account Management — who changed accounts and group membership
Event ID Meaning Importance 4720 A user account was created High 4722 A user account was enabled (covers computer objects too) High 4723 An attempt was made to change an account's password (user changing their own) Medium 4724 An attempt was made to reset an account's password (an admin resetting someone else's) High 4725 A user account was disabled High 4726 A user account was deleted Very high 4740 A user account was locked out High — check the Caller Computer Name field 4728 A member was added to a security-enabled global group (Domain Admins, for example) Very high 4732 A member was added to a security-enabled local group (on a DC that means domain-local: Builtin\Administrators, Account Operators) Very high 4756 A member was added to a security-enabled universal group (Enterprise Admins, Schema Admins) Very high
The 4728/4732/4756 rows are where most write-ups go wrong. A lot of them gloss 4728 as "member added to a security group", which is too vague to act on. All three are security groups. What separates them is group scope — global, domain-local, universal respectively, as Microsoft's Audit Security Group Management page sets out. The practical consequence: watch 4728 alone and you see additions to Domain Admins, while you stay blind to Enterprise Admins and Schema Admins (universal, so 4756) and blind to Builtin\Administrators on a domain controller (domain-local, so 4732). Both of those are routes to the same level of control.
There is also a naming trap here. 4740 sounds like it belongs to the "Audit Account Lockout" subcategory, but it actually sits under Audit User Account Management. The subcategory named Account Lockout holds 4625 instead. They are swapped relative to what the names imply, which matters if you enable auditing at subcategory granularity.
Account Logon — 4769 and 4771 on domain controllers only
Event ID Meaning Importance 4776 The computer attempted to validate the credentials for an account (NTLM) High — check the Error Code 4771 Kerberos pre-authentication failed Very high — the DC-side counterpart to 4625; check the Failure Code 4769 A Kerberos service ticket was requested Medium — naturally very high volume
This is the group most AD logging articles leave out entirely, and it is the group you cannot do without if you want to catch brute force against domain accounts. The header above is deliberately narrow: 4769 and 4771 are DC-only, while 4776 is generated on whichever machine is authoritative for the credentials — the DC for domain accounts, but the workstation itself for a local account.
4625 is not always the event you get on a DC. Microsoft documents that 4625 is generated on the computer where the logon attempt was made. A domain account failing over Kerberos therefore surfaces on the DC as 4771 . On the NTLM side it surfaces as 4776 with an Error Code other than 0x0. Point a 4625-only brute force rule at your domain controllers and you are watching the wrong door.
Only a handful of error and status codes matter, and they separate attacker behavior cleanly: 0xC0000064 means no such username exists (someone is enumerating account names), 0xC000006A means the username is valid but the password is wrong (brute force or password spray), and 0xC0000234 means the account is already locked out.
4776 also comes with two limits worth knowing. It is not generated when a domain account logs on locally to a DC, and it carries only the source workstation name — no IP address, and nothing about the destination.
Five alerts worth configuring
The rules below are written without reference to any particular SIEM; anything that can correlate events will run them. (If you are still working out where log management ends and SIEM begins, start with what SIEM is .)
One thing matters more than any individual rule: treat every threshold below as a starting point, and expect to move it. Run each rule in monitor-only mode for at least two weeks to baseline it before you let it wake anyone up at night. An environment full of batch jobs and an environment without them produce numbers that are not remotely comparable.
1. Brute force against a single account
Rule (Kerberos): 4771 with Failure Code 0x18, same target account, > 10 in 5 minutes
Rule (NTLM): 4776 with Error Code 0xC000006A, same target account, > 10 in 5 minutes
Correlate: for 4771, use Client Address — the source IP of the request;
4776 has no IP field at all, so key on Source Workstation,
or on target account + error code
Microsoft's own 4771 documentation points the same way, noting that repeated Failure Code 0x18 events in a short window can indicate a brute force attack on the account password, particularly for critical accounts. It also recommends tracking Client Address values per account name, which is why that field belongs in the rule rather than the 4624-style Source Network Address a lot of templates copy in.
2. A new admin account appears
Rule: 4720 (account created) followed by 4728 OR 4732 OR 4756 within 1 hour,
where the destination group is on a privileged-group watchlist
Minimum watchlist: Domain Admins, Enterprise Admins, Schema Admins,
Builtin\Administrators, Account Operators, Backup Operators
All three membership events have to be in the rule, for the group-scope reason above. A rule that only watches 4720 plus 4728 misses two of the three routes to forest-level privilege.
3. Logon outside business hours
Rule: 4624 between 22:00 and 06:00
Filter first, always:
- keep only Logon Type 2 (interactive) and 10 (RemoteInteractive/RDP)
- drop machine accounts (names ending in $)
- drop SYSTEM, NETWORK SERVICE, LOCAL SERVICE
Without those three filters the rule fires on every backup job, scheduled task and service start, every night, until nobody reads it. The other thing people forget is that the time window is evaluated against the DC's own clock and time zone, which is a real problem for organizations with overseas shifts.
4. Password spray
Rule: 4771 (0x18) or 4776 (0xC000006A) across 15 or more DISTINCT target accounts
within a 30-60 minute window
Separate rule: 0xC0000064 (no such username) = account name enumeration in progress
The one-minute window you see repeated all over the internet is far too tight. Password spraying is deliberately slow so it stays under the lockout threshold — one attempt per account, then wait. The variable to count is the number of distinct accounts , not the total number of attempts.
Every rule here ends at the same next question: what else did that account touch, and where. Answering it means the events already sit somewhere you can pivot on them — filtering by username across every domain controller at once, instead of opening Event Viewer on each box in turn. That search pass is the everyday job of a log platform; in zcrLog it is the Log Viewer, with Username, Event ID, Source Device, Protocol and Severity as filter fields over the whole stream.
5. Kerberoasting
Rule: 4769 meeting all three conditions at once
1) Ticket Encryption Type is not 0x11 or 0x12 (not AES) — 0x17 is RC4-HMAC
2) Service Name resolves to a user account with an SPN, excluding
computer accounts (whose names end in $)
3) a single account requesting many DISTINCT Service Names in a short window
This is the rule most AD articles get wrong. The version you usually see is "abnormally high volume of 4769", which does not work, because 4769 is generated every time the KDC receives a service ticket request, and Microsoft's subcategory documentation already rates its event volume as "Very High" on KDC servers. A volume-based rule fires on Monday morning when everyone logs on at once, and again after a patch reboot.
Condition 1 only tells you what to look at first. On its own it proves nothing: an attacker can request AES, and any environment still permitting RC4 has legitimate RC4 traffic that will match. Conditions 2 and 3 are what make the rule usable.
Worth knowing because it is recent: Windows Server 2016 and later, with the 14 January 2025 Security Cumulative Update or newer, add fields to 4769 including ClientAdvertizedEncryptionTypes, ServiceSupportedEncryptionTypes and SessionKeyEncryptionType. Those open up a much sharper condition — the client advertised AES but the issued ticket came back RC4 — which is closer to a genuine indicator than encryption type alone.
Once you start looking at 4769 you will also find Failure Code 0x20 everywhere. That means a service ticket expired. Microsoft describes these as informational, with little to no security relevance. Filter them out at the source.
Getting AD logs into a SIEM
Step 1: turn on audit policy at the domain controller
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Management" /success:enable /failure:enable
auditpol /set /category:"Account Logon" /success:enable /failure:enable
Those three lines cover every Event ID in all three tables above with nothing left out — including 4769, which the Kerberoasting rule depends on and which comes from the third line (subcategory Audit Kerberos Service Ticket Operations). The syntax and the category names are exactly as Microsoft documents them.
/category: is a blunt instrument./subcategory: is the surgical alternative, but then you have to enable every subcategory the tables reference: Logon/Logoff alone needs Logon, Logoff, Special Logon and Account Lockout. Enabling just "Logon" silently loses 4634, 4672 and the lockout side of 4625. The extra care costs a few minutes, and on a busy DC it is the difference between a feed your team can live with and a licensing bill that gets escalated.
Adding /failure:enable to the Account Management line does almost nothing for the group events. Microsoft states on the Audit Security Group Management page that this subcategory has no Failure events, so there is no recommendation to enable failure auditing for it.
The third line is the expensive one. Microsoft's own volume ratings: Audit Security Group Management is Low; Audit Logon is Low on a client and Medium on a DC or network server; Audit Kerberos Service Ticket Operations is Very High on KDC servers . Size storage and EPS for that up front rather than discovering it later.
One last thing before you type any of it into a production box: auditpol writes local policy. If audit settings are managed through Group Policy (Advanced Audit Policy Configuration), the next GPO refresh overwrites everything you just entered. For anything that is not a lab machine, configure it in GPO, and spare yourself an afternoon wondering why auditing quietly reverted.
Step 2: pick how events leave Windows
Windows does not emit syslog on its own. There are two real options.
Install an agent or forwarder on the host. NXLog, winlogbeat, or the SIEM vendor's own agent. Each reads the Windows Event Log and ships it out as syslog straight to your collector.
Use WEC/WEF. Windows Event Collector and Windows Event Forwarding are built in, and let endpoints forward events to a single Windows collector without installing anything on each machine. The catch is where that path ends: WEF delivers to a Windows collector and stops there. You still need a forwarder on that collector to relay into a syslog-based SIEM. It is not a direct route.
Step 3: set retention longer than the law asks for
Ninety days is the ordinary minimum for traffic data under Section 26; an official can order longer, and the notification has other requirements too. It is a poor fit for the questions an investigation actually asks. Three questions in particular reach past the compliance window. When was this account first compromised, as opposed to when did we notice it. Is this week's authentication pattern unusual measured against the same week last year. And the one that hurts most: a partner, a bank or a law enforcement notification lands on your desk describing a breach from six months ago, and the window you would need to check it against closed three months back. A year of authentication data gives you a shot at all three.
Where zcrLog sits on this is worth being specific about, because it differs by deployment. The published SaaS and Dedicated VM tiers both run 90-day retention. zcrLog's product FAQ puts the configurable range at anything from one day up to ten years, with MD5, SHA-1 and SHA-256 hashing plus AES-128 encryption behind the integrity guarantee. If a full year of authentication logs is what you need, that is a sizing and deployment conversation to have up front.
zcrLog and Active Directory
See the zcrLog product page for more on how the Log Viewer's System Logs tab works.
Windows events, domain controllers included, land in System Logs with their fields already parsed out. A Source Type column separates Windows from the Linux syslog and Cisco ASA feeds arriving on the same stream. A Windows Security event forwarded from a domain controller carries its Event ID, the user, the source hostname, the protocol — Kerberos, WinRM and RDP among them — and a risk rating, each in its own filterable column rather than buried in raw text you have to write a regex against. Which Event IDs actually turn up is a function of the audit policy you set in Step 1 and what your forwarder ships.
The columns that matter for AD work are Event, User, Source Hostname, Protocol, Severity, Severity Score, Risk Score, Risk Level and Action. Filters cover Username, Event ID, Source Device, Source IP/Hostname, Protocol and Severity, which is enough for the "what did this account do during that window" pass. Time ranges run from 5 minutes to 24 hours plus custom, with auto-refresh and a Live mode.
Cloud identity sits on a separate tab. Microsoft Entra ID gets its own, split into Audit Logs and Sign-in Logs, with a Sync Now button and filters for Category, Status, Actor Email and Target Type. Entra ID, Microsoft 365 (Exchange, SharePoint and Teams audit logs through the Office 365 Management API), AWS CloudTrail, Google Cloud audit logs, SentinelOne and CrowdStrike Falcon are among the cloud and endpoint sources zcrLog collects today; Google Workspace and Okta are on the roadmap, not shipping yet. (Configuring that side is covered in collecting logs from Microsoft Entra ID .)
Where this stops. For on-premises AD there is no one-click integration card of the kind Entra ID has. Getting Windows events in is a forwarding job over syslog or an agent, exactly as described in Step 2 above. If you are comparing SIEM vendors, ask all of them this same question, because plenty of them describe both situations as "AD support".
See zcrLog pricing and packages →
Contact
If you want a second opinion on whether your current audit policy and retention settings actually cover you, talk to the team:
Sources
Products | Pricing | Resources | Insights | Contact 