Windows Domain Controller Security Monitoring: Building an Event Log Detection Baseline

Domain controllers generate a high volume of security-relevant events. Without a curated audit policy and well-tuned detection rules, the signal is buried in noise — and the events that matter most (privileged account creation, Golden Ticket use, LSASS access) go undetected. This guide establishes the minimum viable monitoring baseline for Windows domain controllers.

Step 1: Audit Policy Configuration

Windows audit policy controls which categories of events are logged. The default Windows Server audit policy is insufficient for security monitoring. Apply the following via Group Policy to all domain controllers:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration

Audit Account Logon Events:
  - Credential Validation: Success and Failure
  - Kerberos Authentication Service: Success and Failure
  - Kerberos Service Ticket Operations: Success and Failure

Audit Account Management:
  - Computer Account Management: Success
  - Distribution Group Management: Success
  - Security Group Management: Success
  - User Account Management: Success and Failure

Audit DS Access:
  - Directory Service Access: Failure
  - Directory Service Changes: Success

Audit Logon/Logoff:
  - Logon: Success and Failure
  - Logoff: Success
  - Special Logon: Success

Audit Object Access:
  - SAM: Success and Failure (for LSASS access detection)

Audit Policy Change:
  - Audit Policy Change: Success and Failure
  - Authentication Policy Change: Success

Audit Privilege Use:
  - Sensitive Privilege Use: Success and Failure

Audit System:
  - Security System Extension: Success
  - System Integrity: Success and Failure

Additionally, enable command line logging for process creation (Event ID 4688):

Computer Configuration → Administrative Templates → System → Audit Process Creation
Enable "Include command line in process creation events"

Step 2: Critical Event IDs and Detection Rules

These event IDs should generate alerts in your SIEM:

Privileged account operations:

• 4728 — Member added to a security-enabled global group (Domain Admins, Enterprise Admins)
• 4732 — Member added to a security-enabled local group (Administrators on DC)
• 4756 — Member added to a security-enabled universal group
• 4720 — User account created (alert if new account, review within 1 hour)
• 4726 — User account deleted

Suspicious authentication:

• 4625 — Failed logon on a DC from external IP addresses (source IP outside corporate RFC1918 ranges)
• 4771 — Kerberos pre-authentication failure with error code 0x18 (wrong password) at high volume
• 4769 — Kerberos service ticket request with Ticket Encryption Type = 0x17 (RC4-HMAC) from accounts in Protected Users group (Golden Ticket indicator)

Process and privilege abuse:

• 4688 — New process creation where Creator Subject Security ID is SYSTEM and New Process Name is a shell or unexpected executable
• 4672 — Special privileges assigned to new logon from an unexpected account
• 7045 — New service installed on a DC

LSASS access (requires Sysmon or process access auditing):

• Sysmon Event ID 10 (ProcessAccess) targeting lsass.exe with GrantedAccess 0x1fffff from non-security tool processes

Step 3: SIEM Pipeline Requirements

Collecting the right events only provides value if the SIEM pipeline meets these requirements:

Retention: 90 days hot (searchable immediately), 1 year cold (accessible within hours). DC security logs are forensic evidence in breach investigation and must be retained accordingly.

Forwarder reliability: Windows Event Forwarding (WEF) or agent-based forwarding must be monitored for gaps. A DC whose logs are not reaching the SIEM creates a blind spot attackers can exploit. Alert if DC log forwarding stops for more than 15 minutes.

Alert SLA: DC security alerts require human review within 30 minutes. A Golden Ticket detection that is reviewed 4 hours later — after the attacker has completed lateral movement — provides no security benefit.

Baseline deviation: Static alerting rules miss attacker behaviour that blends with normal patterns. Implement baseline deviation for Kerberos service ticket volume per account — a sudden spike in tickets from an account that normally generates 10 per hour to 5,000 per hour is an indicator regardless of whether the tickets are for known services.

Step 4: Verification Testing

After configuring the audit policy and SIEM rules, verify they work as intended:

1. Create a test account test-sec-monitoring and add it to a non-privileged group — verify Event IDs 4720 and 4728 appear in SIEM
2. Simulate a failed Kerberos authentication — verify 4771 alert fires
3. Use mimikatz::lsadump::lsa /patch in a test environment to verify LSASS access alerts trigger
4. Create a test service with sc create on a test DC — verify 7045 alert triggers

Document the test results as evidence that the monitoring baseline is functional. This documentation is required for any SOC 2 or ISO 27001 evidence collection relating to privileged access monitoring.