Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

[star]Ask the Directory Services Team
November 2, 2009 12:13
by NedPyle
Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

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.

[image]

On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.

[image]

When you edit your built-in Default Domain password policy, you are actually editing:

\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\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=” 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?”

[image]

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.

[image]

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: CONTOSO\Administrator
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=” object causes Windows to track all users who write, delete, and modify permissions on any FGPPs.

[image]

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: CONTOSO\RobGreene
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: CONTOSO\RobGreene
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

audit Authentication Windows Server 2008 Windows Server 2008 R2

2 Responses to Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

  1. MarcJ says:

    Hi Ned,

    Nice and helpful post. I was wondering if you knew of any free tools that could help in determining the resultant password policy for domain user accounts in Windows Server 2008?

    I ask because I run a community blog on Free Active Directory Reporting Tools and I was looking for a free tool that I could share for everyone’s benefit.

    If you know of any tools, could you please let me know?

    Thanks man,

    Ciao,
    Marc

  2. Pingback: 2010 in review « JC’s Blog-O-Gibberish

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Exchange Goddess

I'm here for the refreshments. About cows, goats, and surviving in IT as a woman

A bit of Exchange & Office 365

Blog of an Exchange Microsoft Certified Master & MVP

NorthernLync

The World of Lync 2010 & Lync 2013

The Lync

Tom Kisner's Microsoft Unified Communications Blog

msunified.net

Technical blog about Exchange, OCS and Lync by Ståle Hansen

My Exchange Link

An another Exchange fellow !!!

ODDYTEE

All about messaging (and maybe some other stuff too).

www.WeakestLync.com

Follow on Twitter @WeakestLync

Unified Blog

Focused on Unified Communications & Collaboration

Unified Communications...

...The Microsoft Lync Way

Chad McGreanor's Blog

Engineers Notebook

Thoughtsofanidlemind's Blog

Exchange, Office 365, technology, and anything else really...

Working Hard In IT

My view on IT from the trenches

Steve Goodman's Exchange & Office 365 Blog

The weblog of an Microsoft MVP and IT Pro specialising in Exchange, Lync, Office 365. Guides, Tutorials, How-Tos and commentary.

Ehlo World!

All about Microsoft Unified Communications

Michael 'Van Hybrid' / Van Horenbeeck

My personal trash of thoughts about Unified Communications and stuff

Migration Life

Blog for Active Directory and Exchange migration projects

Follow

Get every new post delivered to your Inbox.

Join 1,191 other followers

%d bloggers like this: