Windows Security Auditing: Configuration Artifacts and Event Reference

1.1. Basic Audit Policy Categories

Basic audit policies define broad categories of events to monitor. Enabling these categories forms the foundation of an audit policy. This is the older method of configuration. Advanced Audit Policy (see next section) provides significantly more granularity and is generally recommended for modern systems.¹

1.2. Advanced Audit Policy Configuration Categories and Subcategories

Advanced Audit Policies offer fine-grained control over audited events, allowing administrators to target specific activities and reduce event log noise compared to Basic policies. These settings are accessible via Local Security Policy (secpol.msc) or Group Policy. Using Advanced Audit Policy is the preferred modern approach.²

1.3. Example SDDL Snippet: SYSTEM_AUDIT_ACE

A System Access Control List (SACL) contains Access Control Entries (ACEs) that specify which access attempts trigger security audits. The SYSTEM_AUDIT_ACE type is used for this purpose within the Security Descriptor Definition Language (SDDL) representation of a SACL. Remember, a SACL must be configured on the specific object (file, folder, registry key, etc.) you want to audit, in addition to enabling the relevant audit policy subcategory (like 'Audit File System' or 'Audit Registry').

Example 1: Audit successful File All Access for Everyone

Code snippet

S:(AU;SAFA;FA;;;WD)

• S:: Denotes the SACL component of the SDDL string.
• AU: ACE flag indicating an audit should be generated on successful access attempts. Use AL for failed attempts, or AU;AL for both.
• SA: Specifies the ACE type as SYSTEM_AUDIT_ACE_TYPE.
• FA: Represents the ACCESS_MASK bits being audited. FA corresponds to File All Access (0x1F01FF). Other common masks include WD (Write Data/Add File - 0x00000002), AD (Append Data/Add Subdirectory - 0x00000004), DE (Delete - 0x00010000), RC (Read Control - 0x00020000), FR (File Read Data - 0x00000001).
• (empty): Object Type GUID (usually empty for file/registry ACEs).
• (empty): Inherited Object Type GUID (usually empty for file/registry ACEs).
• WD: Trustee SID. WD represents the well-known SID for Everyone (S-1-1-0). Replace with specific user or group SIDs (e.g., S-1-5-32-544 for BUILTIN\Administrators).

Example 2: Audit failed Read Data and Write Data attempts by a specific user

Code snippet

S:(AL;SA;FRFW;;;S-1-5-21-1234567890-123456789-1234567890-1001)

• AL: ACE flag indicating audit on failure.
• FRFW: Access mask combining FR (File Read Data - 0x1) and FW (File Write Data - 0x2). The combined mask is 0x3. (Note: FW isn't a standard simple mask; this example likely intends Write Data 'WD' - 0x2. Combining FR and WD would be FRWD, mask 0x3).
• S-1-5-21-...-1001: Placeholder for a specific user's SID.

1.4. Common Audit Event IDs

Specific Event IDs in the Security log correspond to activities audited based on policy settings. Monitoring key IDs is essential for security analysis. The tables below list some common event IDs associated with the policy categories.

2.1. Local Security Policy (.reg Snippets)

Registry files can directly configure *some* local audit policy settings, but this is often not the recommended method, especially for Advanced Audit Policy or Basic policy which uses opaque storage. Use tools like secpol.msc or auditpol.exe for local configuration.

Basic Audit Policy Example: Audit Logon Events (Success and Failure)

Code snippet

Windows Registry Editor Version 5.00

; This value is part of a binary structure managed by LSA.
; Direct modification is complex and not recommended. Use secpol.msc or GptTmpl.inf instead.
; Example below illustrates the CONCEPTUAL location but is NOT directly usable.
; AuditCategoryLogon = 3 (Success=1, Failure=2 -> Both=3)
; Note: The actual registry storage for basic policy in PolAdtEv is opaque.

; Configures: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\Audit logon events
; Setting this via secpol.msc (which modifies PolAdtEv) is the supported method for local basic policy.

Advanced Audit Policy Example: Audit File System (Success Only)

Code snippet

Windows Registry Editor Version 5.00

; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access\Audit File System
; Note: Advanced Audit Policy set locally via secpol.msc or auditpol.exe is not stored in simple, documented registry values.
; Use auditpol.exe or secpol.msc for local configuration. GPO settings are stored under HKLM\Software\Policies.
; The effective policy reflecting the merge of local and GPO settings is readable via 'auditpol /get'.
; Direct registry manipulation for local Advanced Audit Policy is NOT supported.

Enforce Advanced Audit Policy over Basic Policy

This setting, configurable via Registry or GPO, forces the system to use *only* Advanced Audit Policy settings if they are configured, ignoring legacy Basic Audit Policy settings.

Code snippet

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"SCENoApplyLegacyAuditPolicy"=dword:00000001

; Configures: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
; Value = 1 enables enforcement (Advanced overrides Basic)
; Value = 0 disables enforcement (Basic settings may merge or conflict with Advanced)

Rationale: Setting SCENoApplyLegacyAuditPolicy to 1 is crucial when using Advanced Audit Policy to ensure its granular settings take precedence and are not overridden or unpredictably merged with broader Basic Audit Policy settings.²

2.2. Group Policy Objects (GPOs)

GPOs provide centralized management of audit policies across multiple machines in an Active Directory domain. This is the standard method for enterprise environments.

Advanced Audit Policy: audit.csv Structure and Example

This file resides in the GPO path \Machine\Microsoft\Windows NT\Audit\ within SYSVOL. It defines Advanced Audit Policy settings.

Format: Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value

Content Example:

Code snippet

Machine Name,Policy Target,Subcategory,Subcategory GUID,Inclusion Setting,Exclusion Setting,Setting Value
*,System,Logon,{0CCE9215-69AE-11D9-BED3-505054503030},*,*,3
*,System,File System,{0CCE921D-69AE-11D9-BED3-505054503030},*,*,1
*,System,Process Creation,{0CCE922B-69AE-11D9-BED3-505054503030},*,*,3
*,System,Audit Policy Change,{0CCE9217-69AE-11D9-BED3-505054503030},*,*,1

• Machine Name: Usually *.
• Policy Target: System.
• Subcategory: Human-readable name (informational).
• Subcategory GUID: The unique identifier for the subcategory (critical).
• Inclusion Setting: Usually *.
• Exclusion Setting: Usually *.
• Setting Value: 0=No Auditing, 1=Success, 2=Failure, 3=Success and Failure.

Basic Audit Policy: GptTmpl.inf Example Lines

This file resides in the GPO path \Machine\Microsoft\Windows NT\SecEdit\ within SYSVOL. It defines various security settings, including Basic Audit Policy under the [System Access] section (note: OCR showed `` section, likely meant System Access).

Content Example:

Ini, TOML

[Unicode]
Unicode=yes

[System Access]
; AuditAccountLogon: 0=No Auditing, 1=Success, 2=Failure, 3=Success and Failure
AuditAccountLogon = 3
AuditObjectAccess = 1
AuditPolicyChange = 3
;... other basic categories...

[Version]
signature="$CHICAGO$"
Revision=1

Client-Side Registry Keys Reflecting Applied GPO Settings

GPO settings are applied to specific registry locations on client machines. These keys reflect the *result* of GPO application.

Basic Audit Policy (from GPO):

Code snippet

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\Policy]
; Reflects GPO settings for Basic Audit Policy Categories
; Exact values depend on GPO configuration. Example shows Logon=Success/Failure, ObjectAccess=Success.
"AuditAccountLogon"=dword:00000003
"AuditObjectAccess"=dword:00000001
;... other categories...

Advanced Audit Policy (from GPO):

Code snippet

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9215-69AE-11D9-BED3-505054503030}]
; Reflects GPO settings for Advanced Audit Policy Subcategories
; Keys are named by Subcategory GUID. Example shows Logon and File System.
"Setting"=dword:00000003 ; Logon (Success and Failure)

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE921D-69AE-11D9-BED3-505054503030}]
"Setting"=dword:00000001 ; File System (Success)

GPO Enforcement of Advanced over Basic:

Code snippet

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Audit]
; Reflects GPO setting for forcing Advanced over Basic policy
"SCENoApplyLegacyAuditPolicy"=dword:00000001

2.3. auditpol.exe Commands

The auditpol.exe utility manages Advanced Audit Policy settings on the local machine. Changes made here configure the *local* policy layer, which may be overridden by GPO settings unless GPO is not configured or the local setting is enforced.

Set Subcategory Auditing:

Code snippet

:: Enable Logon events for Success and Failure
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

:: Enable File System auditing for Success only
auditpol /set /subcategory:"File System" /success:enable /failure:disable

:: Enable Audit Policy Change events for Success and Failure
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

:: Disable Process Creation auditing
auditpol /set /subcategory:"Process Creation" /success:disable /failure:disable

Backup Current Audit Policy:

Code snippet

auditpol /backup /file:"C:\Temp\AuditPolicyBackup.csv"

Restore Audit Policy from File:

Code snippet

auditpol /restore /file:"C:\Temp\AuditPolicyBackup.csv"

View Current Effective Audit Policy:

Code snippet

auditpol /get /category:*

Note: This command displays the *effective* audit policy currently enforced on the system, reflecting the merged result of local settings and applied GPOs, considering the SCENoApplyLegacyAuditPolicy setting.

2.4. System Access Control Lists (SACLs) on Objects

SACLs define object-specific auditing rules. They are configured directly on the object's Security Descriptor (e.g., file, folder, registry key). Remember, the corresponding Advanced Audit Policy subcategory (e.g., "Audit File System", "Audit Registry") must also be enabled for SACL entries to take effect.

Understanding SACL Components (How to Configure Auditing)

When configuring a SACL entry (often called an Audit ACE), you need to specify several key components:

• Principal: Who is being audited? This is the user or group whose actions you want to monitor. It's specified using their name or, more reliably, their Security Identifier (SID). Examples: `Everyone`, `BUILTIN\Administrators`, `S-1-5-21-...-1001`.
• Type: Which outcomes trigger an audit? You can audit `Success` attempts, `Failure` attempts, or `All` (`Success` and `Failure`). This corresponds to the `AU` (Audit Success) and `AL` (Audit Failure) flags in SDDL.
• Applies to: (Mainly for folders/registry keys) Where does this rule apply? Does it apply only to this object, or should it be inherited by child objects (subfolders, files, subkeys)? This controls inheritance behavior.
• Permissions / Access Mask: What specific actions trigger the audit? This defines the activities being monitored. You select specific permissions like `ReadData`, `WriteData`, `Delete`, `ReadPermissions`, or broader masks like `FullControl` (`FA` in SDDL), `Read` (`FR`), `Write` (`FW` or `WD`), etc. Only access attempts matching *both* the Principal *and* one of the specified Permissions *and* the Type (Success/Failure) will trigger an audit event (like Event ID 4663 for files/folders or 4657 for registry).

These components are configured using tools like the GUI Security tab (Advanced button -> Auditing tab), icacls.exe, or PowerShell cmdlets like Get-Acl/Set-Acl.

Configure File SACL using icacls.exe:

Code snippet

:: Target file: C:\sensitive\data.txt
:: Audit SUCCESSFUL Delete attempts by BUILTIN\Administrators
:: Audit SUCCESS and FAILURE WriteData (WD) and AppendData (AD) attempts by Everyone

icacls C:\sensitive\data.txt /audit BUILTIN\Administrators:(S):(DE) Everyone:(S,F):(WD,AD)

• /audit: Specifies SACL modification.
• Principal: User or group name (e.g., Everyone, BUILTIN\Administrators).
• (S,F): Audit flags - S=Success, F=Failure. Comma separates multiple flags. Use just (S) or (F) if needed.
• :: Separator. (Note: OCR showed `::`, but icacls typically uses a single colon).
• (Permissions): Comma-separated list of granular permissions (e.g., DE=Delete, WD=WriteData, AD=AppendData, FA=Full Access, RA=Read Attributes, RD=Read Data).

Configure Registry SACL using PowerShell:

PowerShell

# Target Key: HKLM:\SOFTWARE\MyApp
# Audit SUCCESS and FAILURE SetValue and Delete attempts by the 'Users' group (SID S-1-5-32-545)

$RegPath = "HKLM:\SOFTWARE\MyApp"
# Use a well-known SID or retrieve SID for a specific group/user if needed
$PrincipalSID = [System.Security.Principal.SecurityIdentifier]::new("S-1-5-32-545") # BUILTIN\Users SID

# Define the audit rule
# RegistryRights specify the permissions to audit
$AuditRights = [System.Security.AccessControl.RegistryRights]::SetValue,
               [System.Security.AccessControl.RegistryRights]::Delete
# AuditFlags specify Success and/or Failure
$AuditFlags = [System.Security.AccessControl.AuditFlags]::Success,
              [System.Security.AccessControl.AuditFlags]::Failure

# Create the AuditRule object
$AuditRule = [System.Security.AccessControl.RegistryAuditRule]::new(
    $PrincipalSID,
    $AuditRights,
    [System.Security.AccessControl.InheritanceFlags]::None, # Adjust inheritance if needed
    [System.Security.AccessControl.PropagationFlags]::None, # Adjust propagation if needed
    $AuditFlags
)

# Get the current ACL
try {
    $Acl = Get-Acl -Path $RegPath -Audit
} catch {
    Write-Error "Failed to get ACL for $RegPath. Ensure the key exists and you have permissions. Error: $($_.Exception.Message)"
    return
}

# Add the audit rule
$Acl.AddAuditRule($AuditRule)

# Apply the modified ACL
try {
    Set-Acl -Path $RegPath -AclObject $Acl
    Write-Host "SACL updated for $RegPath"
} catch {
    Write-Error "Failed to set ACL for $RegPath. Ensure you have permissions. Error: $($_.Exception.Message)"
}

Example SDDL SACL Strings:

These represent the SACL part (S:(...)) of an SDDL string, often retrieved using PowerShell's (Get-Acl -Audit).Sddl.

• Audit all successful modifications (GenericWrite, GenericAll) by Everyone:

  Code snippet

  S:(AU;SA;GWGA;;;WD)

  • GW = Generic Write (0x40000000)
  • GA = Generic All (0x10000000)

• Audit failed Read Data (FR) access attempts by a specific user SID:

  Code snippet

  S:(AL;SA;FR;;;S-1-5-21-1234567890-123456789-1234567890-1005)

  • FR = File Read Data (0x00000001)

2.5. Registry Manipulation (Global Object Access Auditing - Policy Enabling)

Global Object Access Auditing (GOAA) applies a system-wide SACL to all objects of a specific type (File System or Registry). It is configured via Advanced Audit Policy subcategories (specifically "File System (Global Object Access Auditing)" and "Registry (Global Object Access Auditing)"). You do not directly write SDDL into arbitrary registry values to enable GOAA itself. The .reg snippets below reflect the GPO-applied settings that enable the *policy setting*; the actual SACL applied globally is defined within the policy object configured via GPO or secpol.msc for that subcategory.

Enable File System Global Object Access Auditing Policy (Success & Failure)

Code snippet

Windows Registry Editor Version 5.00

; Reflects enabling the GOAA policy setting for File System via its corresponding Advanced Audit Policy subcategory registry value, typically via GPO.
; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Global Object Access Auditing\File System

; IMPORTANT: The actual SACL applied globally is configured via the secpol.msc or GPO interface for this subcategory, NOT by placing SDDL directly in the registry here.
; This snippet reflects enabling the policy via GPO; local settings are not stored this way.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9240-69AE-11D9-BED3-505054503030}] ; GUID for "File System (Global Object Access Auditing)"
"Setting"=dword:00000003 ; 3 = Success and Failure

Enable Registry Global Object Access Auditing Policy (Success & Failure)

Code snippet

Windows Registry Editor Version 5.00

; Reflects enabling the GOAA policy setting for Registry via its corresponding Advanced Audit Policy subcategory registry value, typically via GPO.
; Configures: Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Global Object Access Auditing\Registry

; IMPORTANT: The actual SACL applied globally is configured via the secpol.msc or GPO interface for this subcategory, NOT by placing SDDL directly in the registry here.
; This snippet reflects enabling the policy via GPO; local settings are not stored this way.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog\Settings\{0CCE9241-69AE-11D9-BED3-505054503030}] ; GUID for "Registry (Global Object Access Auditing)"
"Setting"=dword:00000003 ; 3 = Success and Failure

Caution: Misconfiguring GOAA can lead to extremely high event volume and performance degradation. Use this feature judiciously and define the global SACL carefully through the policy management tools.²

3.1. Registry Locations

3.2. Group Policy File Paths (Relative to GPT Root)

Audit settings configured via GPO are stored in specific files within the Group Policy Template (GPT) folder structure in SYSVOL (e.g., \\\SYSVOL\\Policies\{GPO_GUID}\).

• Advanced Audit Policy (audit.csv): \Machine\Microsoft\Windows NT\Audit\audit.csv
• Basic Audit Policy / Security Options (GptTmpl.inf): \Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

3.3. Object SACL Retrieval Commands

Commands to retrieve the Security Descriptor, including the SACL, for various object types.

NTFS File/Folder:

• Using icacls.exe (Displays ACEs textually):

  Code snippet

  icacls C:\path\to\file_or_folder
  (Look for AUDIT entries in the output)

• Using PowerShell Get-Acl (Retrieve SDDL string):

  PowerShell

  (Get-Acl -Path C:\path\to\file_or_folder -Audit).Sddl

• Using PowerShell Get-Acl (View Audit Rules as objects):

  PowerShell

  (Get-Acl -Path C:\path\to\file_or_folder -Audit).Audit | Format-List

Registry Key:

• Using PowerShell Get-Acl (Retrieve SDDL string):

  PowerShell

  (Get-Acl -Path "HKLM:\path\to\key" -Audit).Sddl

• Using PowerShell Get-Acl (View Audit Rules as objects):

  PowerShell

  (Get-Acl -Path "HKLM:\path\to\key" -Audit).Audit | Format-List

Active Directory Object:

• Using dsacls.exe (Displays ACEs textually):

  Code snippet

  dsacls "CN=SomeObject,OU=Container,DC=domain,DC=com" /S
  (The /S switch displays the SACL)

• Using PowerShell Get-Acl with ActiveDirectory Provider (Retrieve SDDL string):

  PowerShell

  # Ensure Active Directory PowerShell module is imported
  Import-Module ActiveDirectory -ErrorAction SilentlyContinue
  
  (Get-Acl -Path "AD:CN=SomeObject,OU=Container,DC=domain,DC=com" -Audit).Sddl

4.1. Event XML: File System (Event ID 4663 - Object Access Attempt)

Generated when an attempt is made to access a file or folder object with a matching SACL entry. Requires the "Audit File System" subcategory to be enabled and a relevant SACL on the object.⁶

XML

  
    
    4663
    1
    0
    12800
    0
    0x8020000000000000
    
    123456
    
    
    Security
    WORKSTATION01.corp.contoso.com
    
  
  
    S-1-5-21-111111111-222222222-333333333-1103
    Alice
    CORP
    0x12345
    Security
    File
    C:\sensitive\project_alpha\document.docx
    0x1a4
    %%4417 %%%%4418 %%%%4423 
    0x120196 
    0x2468
    C:\Windows\System32\notepad.exe
    S:AI(AU;SAFA;FA;;;WD) 
  

4.2. Event XML: Process Creation (Event ID 4688)

Generated when a new process starts. Requires the "Audit Process Creation" subcategory to be enabled.⁶

XML

  
    
    4688
    2
    0
    13312
    0
    0x8020000000000000
    
    123460
    
     
    Security
    WKSTN02.corp.contoso.com
    
  
  
    S-1-5-21-111111111-222222222-333333333-1104
    Bob
    CORP
    0x54321
    0x1f4c 
    C:\Windows\System32\cmd.exe 
    %%1936 
    0xabc 
    "cmd.exe" /c "ping 8.8.8.8" 
    S-1-0-0
    -
    -
    0x0
    C:\Windows\explorer.exe 
    S-1-16-8192 
  

4.3. Event XML: Kerberos Authentication Service (Event ID 4768 - TGT Request)

Generated on Domain Controllers when an account requests a Kerberos Ticket Granting Ticket (TGT). Requires the "Audit Kerberos Authentication Service" subcategory to be enabled.⁵

XML

  
    
    4768
    0
    0
    14339
    0
    0x8010000000000000 
    
    789101
    
    
    Security
    DC01.corp.contoso.com
    
  
  
    svc_backup 
    CORP.CONTOSO.COM
    S-1-5-21-111111111-222222222-333333333-1501
    krbtgt/CORP.CONTOSO.COM 
    S-1-5-21-111111111-222222222-333333333-502
    0x40810010
    0x18 
    %%24 
    2 
    192.168.1.150 
    51234 
    
    
    
  

4.4. Event XML: Policy Change (Event ID 4719 - System Audit Policy Changed)

Generated when the system's audit policy (Basic or Advanced) is modified. Requires the "Audit Audit Policy Change" subcategory to be enabled. This event is critical for detecting potential tampering with security monitoring.⁵

XML

  
    
    4719
    0
    0
    13568
    0
    0x8020000000000000 
    
    123488
    
    
    Security
    MGMTSRV01.corp.contoso.com
    
  
  
    S-1-5-21-111111111-222222222-333333333-500
    Administrator
    CORP
    0x67890
    %%8277 
    {0CCE921D-69AE-11D9-BED3-505054503030} 
    File System 
    %%17923 
  

4.5. Event XML: Registry Access (Event ID 4657 - Registry Value Modified)

Generated when a registry value is created, modified, or deleted, provided the "Audit Registry" subcategory is enabled and a relevant SACL exists on the parent key.⁶

XML

  
    
    4657
    1
    0
    12801
    0
    0x8020000000000000 
    
    123501
    
    
    Security
    APPSRVO1.corp.contoso.com
    
  
  
    S-1-5-18 
    APPSRVO1$
    CORP
    0x3e7
    \REGISTRY\MACHINE\SOFTWARE\MyApp\Settings 
    LogLevel 
    0x2b8
    %%1905 
    0x5d0
    C:\Program Files\MyApp\MyAppService.exe
    %%1873 
    3
    %%1873
    4
  

4.6. Event XML: Handle Manipulation (Event ID 4662 - Operation on Object)

Generated when certain operations (like duplication) are performed on an existing handle to an object. Requires the "Audit Handle Manipulation" subcategory and a relevant SACL. Note: This event often provides less direct security value compared to 4663 or 4657 but can be useful in specific investigations.

XML

  
    
    4662
    0
    0
    12802
    0
    0x8020000000000000 
    
    123515
    
    
    Security
    WKSTN03.corp.contoso.com
    
  
  
    S-1-5-21-111111111-222222222-333333333-1105
    Charlie
    CORP
    0x98765
    Security
    File
    C:\shared\report.pdf
    0x3c4 
    %%1537 
    0x9e8
    C:\Windows\System32\svchost.exe
    
    
  

5.1. SeAccessCheck SACL Logic (Structured Text Flow)

The decision to generate an object access audit occurs within the Security Reference Monitor (SRM) as part of the standard access check routine, typically invoked by functions like NtAccessCheck or related kernel APIs.

1. Initiation: A process requests access to an object. The kernel calls an internal SRM function similar to: SeAccessCheck(SecurityDescriptor, SubjectToken, DesiredAccess, ObjectType,...).
2. DACL Evaluation: The SRM compares the SubjectToken (containing user/group SIDs and privileges) against the Discretionary Access Control List (SecurityDescriptor->Dacl).
3. Access Determination: Based on the DACL check, the SRM determines the GrantedAccess mask (what permissions are actually allowed) and the overall AccessCheckResult (Success or Failure). Access is granted or denied at this point.
4. SACL Check Prerequisite: Independently of the access decision, the SRM checks if a System Access Control List (SecurityDescriptor->Sacl) exists on the object AND if auditing is generally enabled for the ObjectType (via the system audit policy, e.g., "Audit File System" enabled).
5. SACL ACE Iteration: If a SACL exists and auditing is enabled for the type:
   • The SRM iterates through each SYSTEM_AUDIT_ACE within the SACL.
   • For each ACE, the SRM performs the following checks:
     • Trustee Match: Does the ACE's Trustee SID match a SID present in the SubjectToken?
     • Access Mask Match: Does the ACE's ACCESS_MASK contain any bits that correspond to the permissions that were *granted* in the GrantedAccess mask (even if the overall operation failed due to other checks)? Note: Some interpretations suggest it checks against *desired* access, but checking granted access is more common for triggering audits accurately.
     • Outcome Match: Does the ACE's Flags (AU for Success, AL for Failure) correspond to the overall AccessCheckResult determined in Step 3?
     • Audit Trigger: If all checks (Trustee, Access Mask, Outcome) are TRUE for a given ACE, an audit is required. The SRM sets an internal GenerateAudit flag and notes the details of the matching ACE(s).
6. Audit Generation Call: If the GenerateAudit flag is TRUE:
   • The SRM calls an internal audit generation function (e.g., SeOpenObjectAuditAlarm, SeObjectReferenceAuditAlarm).
   • This function is passed necessary context: ObjectType, ObjectName, SubjectToken details (SID, username), DesiredAccess, GrantedAccess, AccessCheckResult, and information from the triggering SACL ACE.
7. Return: The original SeAccessCheck function returns the GrantedAccess mask and the AccessCheckResult to the caller (the kernel mode component handling the object access). The audit generation happens asynchronously or as a side effect.

This flow demonstrates that SACL processing is integral to the access control mechanism itself. Audits are generated only when an access attempt matches the specific conditions (Who, What Access, Success/Failure) defined within a relevant SACL ACE, and the corresponding audit policy is enabled.

5.2. Audit Generation Path (Structured Text Flow)

The overall path from an auditable action to an event log record involves several system components.

1. Audit Trigger Event:
   • Object Access: Security Reference Monitor (SRM) performs SeAccessCheck, determines an audit is required based on SACL match (as described in 5.1), and invokes an internal audit generation function (e.g., SeOpenObjectAuditAlarm). -> Audit Data Prepared (by SRM).
   • Non-Object Event (e.g., Logon, Policy Change, Process Create): Local Security Authority Subsystem Service (LSA), Kernel, or other relevant component detects an auditable event based on system audit policy (Basic or Advanced). -> Audit Triggered & Audit Data Prepared (by LSA/Kernel/Component).
2. Audit Message Generation:
   • Prepared Audit Data (containing subject info, event details, status, etc.) is passed to LSA functions (e.g., via LsaAuditingInterfaces or potentially using Authorization APIs like AuthzGenerateAudit*).
   • LSA formats the data into a standardized audit message structure suitable for the Event Logging service.
3. Event Logging:
   • Formatted Audit Message is submitted to the Windows Event Logging Service (eventlog service).
   • The Event Logging Service may apply further filtering (e.g., based on event source or keywords, though less common for Security log).
   • The service writes the final event record to the Security event log file, typically located at: %SystemRoot%\System32\winevt\Logs\Security.evtx.
4. (Optional) Forwarding/Collection:
   • If Windows Event Forwarding (WEF) is configured, the Event Logging Service forwards the event to a collector.
   • Alternatively, SIEM agents or other monitoring tools may read events directly from the Security.evtx log file or via Event Tracing for Windows (ETW) sessions consuming security events.

This pathway highlights the roles of the SRM (for object access triggers), LSA (as a central policy checker, audit formatter, and interface to logging), and the Event Logging Service (as the final writer to the persistent log file).