Domain Auditing¶
The Audit Policy page applies to a DC unchanged. A DC also does things no other machine does: it issues Kerberos tickets, manages computer accounts, and holds the directory itself. The Domain Controller profile adds subcategories for each of those, and the STIG adds audit entries on the directory objects that matter most.
DC-only subcategories¶
Set in the Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration, or with auditpol on the DC.
| CIS | Category | Subcategory | Value | What it catches |
|---|---|---|---|---|
| 17.1.2 | Account Logon | Audit Kerberos Authentication Service | Success and Failure | Every ticket-granting ticket request (event 4768). Failures with code 0x18 are wrong passwords against the domain; a burst of them is password spraying. |
| 17.1.3 | Account Logon | Audit Kerberos Service Ticket Operations | Success and Failure | Every service ticket request (4769). A user requesting tickets for many services at once is Kerberoasting. |
| 17.2.2 | Account Management | Audit Computer Account Management | Success | Computers joined, changed, or removed (4741, 4742, 4743) |
| 17.2.3 | Account Management | Audit Distribution Group Management | Success | Distribution groups changed; rarely security-relevant, cheap to keep |
| 17.2.4 | Account Management | Audit Other Account Management Events | Success | Password policy checks and password hash access (4782) |
| 17.4.1 | DS Access | Audit Directory Service Access | Failure (STIG: Success too) | Attempts to read directory objects that have an audit entry, denied (4662) |
| 17.4.2 | DS Access | Audit Directory Service Changes | Success | Attribute changes on directory objects (5136 to 5141), including group membership and ACL changes, with before-and-after values |
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable
auditpol /set /subcategory:"Distribution Group Management" /success:enable
auditpol /set /subcategory:"Other Account Management Events" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable
Add these to the auditpol block on the Audit Policy page and run the whole thing on the DC.
Audit entries on directory objects¶
Directory Service Access only logs when an object has a SACL (an audit entry) naming what to log. The STIG (WN22-DC-000170 to 000220) wants specific objects to log failed access by anyone and successful writes by anyone: the domain object, the Infrastructure object, the Domain Controllers OU, AdminSDHolder, RID Manager$, and the Policies container that holds every GPO. These are the objects an attacker touches to take over a domain quietly.
The defaults on a fresh domain already include most of the success entries. What to add on each object: dsa.msc → View → Advanced Features → right-click the object → Properties → Security → Advanced → Auditing → Add → Principal Everyone, Type Fail, Full control, Applies to This object only (for the Policies container, This object and all descendant objects).
| Object | Where in dsa.msc |
|---|---|
| Domain | The domain root node |
| Infrastructure | domain → Infrastructure |
| Domain Controllers OU | domain → Domain Controllers |
| AdminSDHolder | domain → System → AdminSDHolder |
| RID Manager$ | domain → System → RID Manager$ |
| Policies | domain → System → Policies |
Read what's there from PowerShell:
(Get-Acl "AD:\DC=corp,DC=local" -Audit).Audit | Select IdentityReference, AuditFlags, ActiveDirectoryRights
(Get-Acl "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" -Audit).Audit | Select IdentityReference, AuditFlags, ActiveDirectoryRights
An object with no audit entries at all was stripped; put the defaults back with the steps above.
Reading a DC's Security log¶
The events worth knowing on a DC, on top of the ones on the Reading the Log page:
| Event | Meaning |
|---|---|
| 4768 | Kerberos TGT requested. Failure code 0x18 = bad password, 0x12 = account disabled or locked, 0x6 = no such user (username guessing) |
| 4769 | Service ticket requested. Many in a second from one user, with encryption type 0x17 (RC4), is Kerberoasting |
| 4741 / 4743 | Computer account created / deleted |
| 4728, 4732, 4756 | Member added to a global, local, or universal security group. Watch Domain Admins and Administrators. |
| 5136 | Directory object modified: which attribute, old and new value |
| 4662 | Directory object accessed; with the DS-Replication-Get-Changes GUIDs (1131f6aa…, 1131f6ad…) it means someone pulled password hashes (DCSync) |
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4728,4732,4756} -MaxEvents 30 | Format-List TimeCreated, Message
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768} -MaxEvents 200 | Where { $_.Message -match '0x18' } | Group { ($_.Message -split 'Client Address:\s+')[1].Split("`n")[0] } | Sort Count -Desc
The second command groups failed TGT requests by source address; the top entry is where the guessing came from.
Verify¶
auditpol /get /category:"Account Logon","Account Management","DS Access"
Example¶
auditpol /get /category:"DS Access" shows both subcategories at No Auditing, and Get-Acl "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" -Audit returns nothing. Someone cleared them so that group membership changes on the protected groups wouldn't be recorded. Turn the subcategories on, restore the audit entries, and then check the Security log for 4728 and 4732 in the last day anyway; the Account Management events were still on.