What is audit logging?

What is audit logging?

Audit logging is the process of recording a chronological trail of events that capture who performed an action, what the action was, when it occurred, and where it originated. In an Active Directory environment, this means every logon attempt, permission change, user account modification, and file access generates an entry in the Windows Security event log.

Think of it as a surveillance system for your IT infrastructure. When a user resets a password on a domain controller, Windows logs Event ID 4724 with the administrator's identity, the target account, the timestamp, and the domain controller that processed the request. That single entry becomes evidence during a security investigation, proof of compliance during an audit, and a diagnostic clue when something breaks.

The terms "audit log" and "audit trail" often appear interchangeably, but they describe different scopes. An audit log is a single record of events from one source, such as the Security event log on a domain controller. An audit trail is the complete chain of audit logs across multiple systems that together reconstruct the full sequence of a user's actions from logon to logoff.

How audit logging works

Audit logging follows a four-stage pipeline: event generation, collection, storage, and analysis.

Event generation begins at the operating system or application level. In Windows, you need to enable auditing through Group Policy first. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies and enable the relevant subcategories, such as Logon/Logoff, Account Management, or Object Access.

Without this step, Windows does not record audit events.

Collection happens locally on each machine that generates the event. Every domain controller, member server, and workstation writes events to its own Security event log. In environments with multiple domain controllers, the same user action (a logon, for example) may generate events on different machines depending on which domain controller authenticated the request.

Storage depends on the Security event log size configured on each machine. The default maximum is 20 MB, after which older events are overwritten. For most production environments, this default is nowhere near enough; logs can disappear within days or even hours.

Analysis is where raw events become useful. Here are the Active Directory Event IDs you'll see most often in audit logs:

Each of these events contains structured fields that identify the actor, the target, the action, and the outcome.

Types of audit logs

Audit logs fall into three categories depending on where the event originates.

In practice, a thorough audit logging strategy needs all three. System-level logs tell you that someone authenticated, but application-level logs tell you what they accessed afterward. User-level logs complete the picture by tracking changes to the identities themselves.

Audit logs vs. operational logs

Audit logs and operational logs serve different purposes, even though both record system events.

This distinction matters because operational logs are often discarded after short retention windows, while audit logs may need to stick around for years. If you apply the same retention policy to both, you'll create compliance gaps and destroy forensic evidence.

What audit log entries contain

A useful audit log entry captures enough context to reconstruct the event without requiring additional investigation. Here are the standard fields in a Windows Security event log entry:

These fields are the basis for filtering, correlation, and alerting. Without Source Network Address, you can't trace a brute-force attack back to its origin. Without Failure Reason, you can't tell whether a user mistyped their password or tried to use a locked account.

Benefits of audit logging

Security incident detection. Audit logs are the primary evidence source when you need to figure out whether a breach occurred, how far it spread, and which accounts were compromised. A sudden spike in Event ID 4625 (failed logon) entries from a single source IP is often the first visible sign of a brute-force attack.

Compliance evidence. Regulatory frameworks don't accept verbal assurances. Auditors want documented proof that access controls are enforced, that privileged actions are tracked, and that you keep this evidence for the mandated period. Audit logs are that proof.

Forensic investigation. When an incident occurs, the audit trail lets you reconstruct the attacker's path. You can trace lateral movement from one workstation to another by correlating logon events across domain controllers, pinpoint the exact time a privilege escalation occurred, and determine which data was accessed before containment.

Insider threat identification. Not every threat comes from outside the network. An administrator who disables auditing, clears the Security event log, or accesses files outside their normal scope generates audit log entries that reveal that behavior. Without audit logging, those actions are invisible.

Operational accountability. When a Group Policy change causes authentication failures across a department, audit logs tell you exactly who modified the GPO, when the change was made, and what settings were altered. You go from "something broke" to "here is who changed what and when" in seconds instead of hours.

Audit logging for compliance

Most regulatory frameworks require organizations to maintain audit logs that capture access to sensitive systems and data. The specifics vary by standard.

Missing these requirements carries consequences beyond fines. PCI-DSS non-compliance can result in increased transaction fees and loss of payment processing privileges. HIPAA violations carry penalties that scale with the severity and duration of the non-compliance.

Security risks of poor audit logging

When audit logging is absent, misconfigured, or insufficiently retained, attackers gain a real advantage. Several well-documented techniques specifically target audit log gaps.

Log clearing. Attackers who gain administrative access to a domain controller can clear the Windows Security event log to erase evidence of their activity. Windows records this action as Event ID 1102, but if no external system captures that event before the log is wiped, the evidence is gone. Clearing event logs is a post-exploitation step documented in the MITRE ATT&CK® framework under technique T1070.001 (Indicator Removal: Clear Windows Event Logs).

Log evasion through timestamp manipulation. Attackers can alter the system clock on a compromised machine (recorded as Event ID 4616) to make their actions appear to have occurred during a different time window, complicating forensic timelines. If audit logs aren't centrally collected with an independent timestamp, this manipulation goes undetected.

Audit policy tampering. By modifying the Advanced Audit Policy Configuration on a domain controller, an attacker can selectively disable auditing for specific event categories. If logon auditing is disabled, subsequent authentication events generate no log entries. Without centralized monitoring of audit policy changes (Event ID 4719), this tampering is invisible to the security team.

Exploitation of default log size limits. The default 20 MB Security event log on a busy domain controller can fill within hours. If the log is configured to overwrite older events (the default behavior), an attacker only needs to generate enough noise, like bulk LDAP queries or service account logons, to push their malicious activity off the log before anyone reviews it.

This isn't theoretical; it's a practical limitation that affects most Windows environments running default configurations.

ADAudit Plus addresses these risks by collecting audit events from all domain controllers in real time and storing them independently of the local Security event log. Even if an attacker clears the log on a domain controller, the events already captured by ADAudit Plus remain intact and available for investigation.

Challenges of audit logging with native tools

Windows provides the Security event log and Event Viewer as built-in audit logging tools, but they carry limitations that make enterprise-scale audit logging difficult.

The most immediate problem is decentralization: each domain controller, member server, and workstation maintains its own Security event log. To determine whether a specific user account was compromised, you need to check the logs on every domain controller that could have processed the authentication. In an environment with ten domain controllers, that means opening Event Viewer on ten separate machines and manually correlating timestamps, Event IDs, and account names.

Native tools offer no real-time alerting. Event Viewer is reactive; you open it after something goes wrong. Windows Task Scheduler can trigger a basic action when a specific Event ID appears, but it can't detect patterns like "five failed logons from different accounts within 60 seconds" that indicate a password spray attack.

By the time an administrator notices the pattern manually, the attack may have already succeeded.

There are no pre-built reports in Event Viewer either. Every report must be constructed manually using XML filters, and the results can't be scheduled for recurring delivery. Compliance teams that need weekly logon activity reports or monthly permission change summaries have to rely on an administrator to manually run and export the data each time.

The default Security event log size of 20 MB isn't enough for most production environments. Increasing it helps, but on-premises storage on each machine still creates a hard ceiling on retention. Compliance frameworks that require multi-year retention can't be satisfied by local event logs alone.

Event Viewer also has no behavioral analysis capability. It records that User A logged on at 3:00 AM, but it has no concept of whether 3:00 AM is normal for User A. Telling the difference between a night-shift employee's routine logon and a compromised account requires baseline comparison that native tools simply don't do.

Cross-platform visibility is another gap. If your environment includes both on-premises Active Directory and Microsoft Entra ID (formerly Azure Active Directory), Event Viewer covers only the on-premises side. Cloud directory events require a separate portal, separate queries, and separate exports, with no correlation between the two.

Monitoring audit logs with ADAudit Plus

ADAudit Plus closes the gaps in decentralization, alerting, and retention that make native audit logging impractical at scale.

What ADAudit Plus monitors

ADAudit Plus collects audit events from all domain controllers, member servers, workstations, and file servers in your environment and pulls them into a single console. You don't need to configure Windows Event Forwarding or visit individual machines to review logs.

The product ships with over 300 pre-configured audit reports covering Active Directory auditing events: logon and logoff activity, user account management (creation, deletion, modification, password changes), group membership changes, GPO settings changes, permission changes with before-and-after values, and file server access across Windows file servers and 13 NAS device types.

For hybrid environments, ADAudit Plus gives you a correlated view of on-premises AD and Microsoft Entra ID events in the same console. You can track a user's on-premises logon, their Entra ID sign-in, MFA status, Conditional Access result, and application access without switching between portals.

The Attack Surface Analyzer detects over 25 named AD attack techniques, including Kerberoasting, Golden Ticket attacks, DCSync attacks, pass-the-hash attacks, and brute-force attacks. Each detection includes a drill-down showing when the attack was attempted, by whom, from which machine, and what it did to the environment.

Real-time alerts notify you by email or SMS when defined events occur. Over 50 default alert profiles cover events like account lockouts, privileged user activity, Security event log clearing, GPO deletions, and permission changes. You can create custom alert profiles for any combination of event type, user, and OU.

You can schedule reports for automatic delivery on an hourly, daily, weekly, or monthly basis and export them in CSV, PDF, HTML, CSVDE, or XLSX format.

For compliance, ADAudit Plus includes dedicated report sets mapped to SOX, HIPAA, PCI-DSS, GDPR, ISO 27001, FISMA, and GLBA. Audit data can be archived for multi-year retention independently of the local Security event log, satisfying the longest retention requirements imposed by any of these frameworks.

Native tools vs. ADAudit Plus

Frequently asked questions