First published on TechNet on Nov 02, 2009
Ned here again. Let’s talk about auditing your domain for changes made to Password and Account Lockout policies. Frankly, it’s a real pain in the neck to figure out Password and Account Lockout auditing and there are legacy architectural decisions behind how this all works, so I’ll make sure to cover all the bases. This also includes auditing your Fine Grain Password policies (FGPP), for you bleeding-edge types.
We use Password and Account Lockout policies to control domain authentication. Password policies set requirements for things like password length, complexity, and maximum age. Account Lockout policies control lockout threshold and duration, and are very popular with The Devil .
There are two types of Password and Account Lockout policies in a domain:
Domain-based policy, while being set through security policy, is actually written to attributes on the root of the domain. ADSIEdit shows this object using the distinguished name of the domain name. This odd location results from providing NT 4.0 compatibility. Since NT 4.0 could not apply group policy, we had to store these values somewhere and answer requests about the settings in an NT fashion.
On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.
When you edit your built-in Default Domain password policy, you are actually editing:
\contoso.comsysvolcontoso.comPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}MACHINEMicrosoftWindows NTSecEdit GptTmpl.inf
All your settings are in this format:
When DC applies this security policy during the five minute group policy refresh, the DC stamps these settings on the domainDNS object. And voila, you have your policies in place. But think about that – the DC stamps these settings in place when applying computer policy. Who do you think will be listed as the user in your audit event logs? That’s right – the DC itself. And that’s where this blog post comes in. :-)
There are three main things you need to do to see domain-wide password and account lockout setting changes, but they differ slightly by OS:
After enabling auditing, Windows then generates security audit events for anyone editing domain-wide security policy for passwords and account lockouts:
You’re probably asking yourself why I didn’t just audit the actual domain root object and skip using the “Authentication Policy Change” and “Other Account Management Events”. This is another of the vagaries of security policy auditing – it doesn’t work. Simply auditing the “DC=domain,DC=com” object does not return any information about password or lockout changes. Go figure.
Auditing FGPP is simpler and the data is easier to read. FGPP does not contain intermediate security policy settings. Creating and modifying these policies directly edits the objects in Active Directory. You can create or modify FGPP using PowerShell , LDP , LDIFDE , or ADSIEDIT . This means there’s no layer between doing work on your behalf. Also, your audit events are clean and self-evident.
After enabling auditing, Windows generates a security audit event for anyone editing FGPPs for each change made. Also, the audit event includes the new value and the value prior to the change:
Here I can see the user RobGreene logged on and changed the password complexity requirements from TRUE to FALSE. I knew it! Rob Greene , always breaking my stuff…
See Edie, I told you I’d write a blog post on this. :-)
- Ned “the chiropractor” Pyle
Ned here again. Let’s talk about auditing your domain for changes made to Password and Account Lockout policies. Frankly, it’s a real pain in the neck to figure out Password and Account Lockout auditing and there are legacy architectural decisions behind how this all works, so I’ll make sure to cover all the bases. This also includes auditing your Fine Grain Password policies (FGPP), for you bleeding-edge types.
Understanding how these policies work
We use Password and Account Lockout policies to control domain authentication. Password policies set requirements for things like password length, complexity, and maximum age. Account Lockout policies control lockout threshold and duration, and are very popular with The Devil .
There are two types of Password and Account Lockout policies in a domain:
- Domain-wide – Introduced in Windows NT and set in Active Directory through domain security policy.
- Fine Grained – Introduced in Windows Server 2008 and set in AD through manual means like ADSIEDIT or AD PowerShell . It configures settings on a user or group-membership basis, and there can be as many as you like.
Domain-based policy, while being set through security policy, is actually written to attributes on the root of the domain. ADSIEdit shows this object using the distinguished name of the domain name. This odd location results from providing NT 4.0 compatibility. Since NT 4.0 could not apply group policy, we had to store these values somewhere and answer requests about the settings in an NT fashion.
On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.
When you edit your built-in Default Domain password policy, you are actually editing:
\contoso.comsysvolcontoso.comPolicies{31B2F340-016D-11D2-945F-00C04FB984F9}MACHINEMicrosoftWindows NTSecEdit GptTmpl.inf
All your settings are in this format:
[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 60
MinimumPasswordLength = 8
PasswordComplexity = 1
PasswordHistorySize = 4
LockoutBadCount = 50
ResetLockoutCount = 30
LockoutDuration = 30
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
ClearTextPassword = 0
LSAAnonymousNameLookup = 0
When DC applies this security policy during the five minute group policy refresh, the DC stamps these settings on the domainDNS object. And voila, you have your policies in place. But think about that – the DC stamps these settings in place when applying computer policy. Who do you think will be listed as the user in your audit event logs? That’s right – the DC itself. And that’s where this blog post comes in. :-)
Auditing Domain-Wide Policy
There are three main things you need to do to see domain-wide password and account lockout setting changes, but they differ slightly by OS:
1. Put an auditing entry on the “Policies” container. Enabling auditing for EVERYONE on the “CN=Policies,CN=System,DC=<your domain>” container causes auditing to track all writes, deletes, and permission modifications. The audit event shows the user modifying group policy in general. Obviously, this is useful for more than just password policy changes – “Hey, who set this policy to push a Domo-Kun wallpaper out to all the computers?”
2. Enable subcategory auditing for:
a. “ Authentication Policy Change ” (if using Windows Server 2008 R2 DC’s).
b. “ Other Account Management Events ” (if using Windows Server 2008 DC’s).
3. Enable subcategory auditing for “ Directory Service Changes ”.
Note: In Windows Server 2008 R2, granular subcategory auditing is available through GPMC.
In Windows Server 2008, you need to use the script provided in KB921469 .
After enabling auditing, Windows then generates security audit events for anyone editing domain-wide security policy for passwords and account lockouts:
1. An event 5136 will be written that shows the versionNumber attribute of the policy being raised:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/24/2009 3:04:17 PM
Event ID: 5136
Task Category: Directory Service Changes
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
Security ID: CONTOSOAdministrator
Account Name: Administrator
Account Domain: CONTOSO
Logon ID: 0x1e936
Directory Service:
Name: contoso.com
Type: Active Directory Domain Services
Object:
DN: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=POLICIES,CN=SYSTEM,DC=CONTOSO,DC=COM
GUID: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
Class: groupPolicyContainer
Attribute:
LDAP Display Name: versionNumber
Syntax (OID): 2.5.5.9
Value: 121
Note: The event ID shows the name of the user that modified the policy – every policy edit raises the version number. Now we know to go look at the policy and that someone changed it.
2. Windows writes a follow-up event (event id 4739) for each type of change – lockout policy or password policy. For example:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/24/2009 3:01:28 PM
Event ID: 4739
Task Category: Authentication Policy Change
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-f-01.contoso.com
Description:
Domain Policy was changed.
Change Type: Lockout Policy modified
Subject:
Security ID: SYSTEM
Account Name: 2008R2-F-01$
Account Domain: CONTOSO
Logon ID: 0x3e7
Domain:
Domain Name: CONTOSO
Domain ID: CONTOSO
Changed Attributes:
Min. Password Age: -
Max. Password Age: -
Force Logoff: -
Lockout Threshold: 500
Lockout Observation Window:
Lockout Duration:
Password Properties:
Min. Password Length:
Password History Length:
Machine Account Quota:
Mixed Domain Mode:
Domain Behavior Version:
OEM Information: -
====
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/24/2009 3:04:23 PM
Event ID: 4739
Task Category: Authentication Policy Change
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-f-01.contoso.com
Description:
Domain Policy was changed.
Change Type: Password Policy modified
Subject:
Security ID: SYSTEM
Account Name: 2008R2-F-01$
Account Domain: CONTOSO
Logon ID: 0x3e7
Domain:
Domain Name: CONTOSO
Domain ID: CONTOSO
Changed Attributes:
Min. Password Age: -
Max. Password Age: -
Force Logoff: -
Lockout Threshold: -
Lockout Observation Window: -
Lockout Duration: -
Password Properties: -
Min. Password Length: 5
Password History Length: -
Machine Account Quota: -
Mixed Domain Mode: -
Domain Behavior Version: -
OEM Information: -
Notice the account name is the DC itself. This event, while useful, needs to be correlated with the 5136 event to see what changed. And even then, these events can sometimes be difficult to understand – what is a “password property” after all? (it’s for complexity being turned on or off). You should probably use these events as a notification to go examine the actual policies in GPMC .
You’re probably asking yourself why I didn’t just audit the actual domain root object and skip using the “Authentication Policy Change” and “Other Account Management Events”. This is another of the vagaries of security policy auditing – it doesn’t work. Simply auditing the “DC=domain,DC=com” object does not return any information about password or lockout changes. Go figure.
Auditing Fine-Grained Policy
Auditing FGPP is simpler and the data is easier to read. FGPP does not contain intermediate security policy settings. Creating and modifying these policies directly edits the objects in Active Directory. You can create or modify FGPP using PowerShell , LDP , LDIFDE , or ADSIEDIT . This means there’s no layer between doing work on your behalf. Also, your audit events are clean and self-evident.
1. Put an auditing entry on the “Password Settings Container” container. Enabling auditing for EVERYONE on the “CN=Password Settings Container,CN=System,DC=<your domain>” object causes Windows to track all users who write, delete, and modify permissions on any FGPPs.
2. Enable subcategory auditing for “ Directory Service Changes ” (see previous section for steps).
After enabling auditing, Windows generates a security audit event for anyone editing FGPPs for each change made. Also, the audit event includes the new value and the value prior to the change:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/24/2009 4:20:54 PM
Event ID: 5136
Task Category: Directory Service Changes
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
Security ID: CONTOSORobGreene
Account Name: RobGreene
Account Domain: CONTOSO
Logon ID: 0x1e936
Directory Service:
Name: contoso.com
Type: Active Directory Domain Services
Object:
DN: CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
GUID: CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
Class: msDS-PasswordSettings
Attribute:
LDAP Display Name: msDS-PasswordComplexityEnabled
Syntax (OID): 2.5.5.8
Value: TRUE
Operation:
Type: Value Deleted
Correlation ID: {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
Application Correlation ID: -
===
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/24/2009 4:20:54 PM
Event ID: 5136
Task Category: Directory Service Changes
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
Security ID: CONTOSORobGreene
Account Name: RobGreene
Account Domain: CONTOSO
Logon ID: 0x1e936
Directory Service:
Name: contoso.com
Type: Active Directory Domain Services
Object:
DN: CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
GUID: CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
Class: msDS-PasswordSettings
Attribute:
LDAP Display Name: msDS-PasswordComplexityEnabled
Syntax (OID): 2.5.5.8
Value: FALSE
Operation:
Type: Value Added
Correlation ID: {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
Application Correlation ID: -
Here I can see the user RobGreene logged on and changed the password complexity requirements from TRUE to FALSE. I knew it! Rob Greene , always breaking my stuff…
See Edie, I told you I’d write a blog post on this. :-)
- Ned “the chiropractor” Pyle