WinSecWiki > Security Settings > Account Policies
Windows Account Policies
Policies here-in are your primary controls over authentication to Windows computers, Active Directory and any application such as SQL Server, IIS or Exchange that rely on integrated Windows authentication
Account Policies Explained
Policies here-in are your primary controls over authentication to Windows computers, Active Directory and any application such as SQL Server, IIS or Exchange that rely on integrated Windows authentication. When you are working with Account Policies in a Group Policy Object or in Local Security Policy it’s very important to understand the context (i.e. which user accounts are actually affected by the Account Policies). Remember that in the Windows environment you have both local SAM accounts and Active Directory domain accounts.
For any given domain, Active Directory enforces just one set of Account Policies on all user accounts in that domain. Active Directory determines the global Account Policies by examining just the GPOs linked to the root of the domain in Active Directory Users and Computers. Account Policies configured in other GPOs have no effect on domain user accounts.
A common mistake Administrators make is to configure different Account Policies for each Organizational Unit in hopes of enforcing custom requirements for different sets of users within the same domain. However Account Policies configured in GPOs linked to OUs have no effect on user accounts within those OUs.
Account Policies configured at the OU level only impact the local account policy for computers within that OU; a computer’s local account policy only affects that computer’s local SAM accounts (i.e. those created in Computer Management\Local Users and Groups).
To determine the Account Policies for a given domain, either manually inspect each GPO linked to the root of the domain in Active Directory Users and Computers, applying group policy’s rules of precedence, or log on to any domain controller within the desired domain run gpedit.msc. When prompted select the local computer’s policy object. The Account Policies you find here are the policies Active Directory has effect for all domain accounts within that domain, having applied all the GPOs linked to the domain root. Note: don’t confuse “root of domain” with “tree root domain” or “forest root domain”.
New Fine Grained Password Policy in Windows Server 2008 Active Directory
Windows Server 2008 Active Directory introduces a new feature called fine grained password policy - which also includes lockout policy.
With this new feature you can for the first type apply different password and lockout policies to different users within the same domain. Prior to this you had one policy for the whole domain, see Account Policies Explained.
Microsoft didn't do this the way I would have which would have simply been to implement it via group policy and allow you to configure different password policies at the organizational unit level.
Anyway, the way it works is you create a new object called a Password Settings Object (PSO). In the PSO you set the same maximum password age, complexity requirements, lockout thresholds, etc that you find under Account Policy in a GPO.
Then you link that PSO to individual users (bad admin!) or to groups (that's it). Note that you have to use groups where the group scope is Global (not Local or Universal) and group type is Security (not Distribution). All members of the group inherit the password and lockout policy defined in the PSO linked to that group.
It's possible for a user to end up with more than one applicable PSO to Windows arbitrates between them based on the msDS-PasswordSettingsPrecedence attribute of each PSO - the lower the value the higher the rank. And PSOs linked directly to a user (bad admin!) take precedence over PSOs assigned through group membership.
Figuring Out If Any PSOs Have Been Defined
Maybe you are conducting an audit and you just need to find out if any fine grained password policies have been defined. Here's what you do. Open Active Directory Users and Computers. Select View\Advanced Features. Then double click the Policies container and then the Password Settings Container. If the container is empty, there are no PSOs defined.
Configuring PSOs
There's no GUI or command line interface in Windows Server 2008 for configuring PSOs - you would have to use ADSI Edit. There are a few free tools available to solve this problem. One is PowerGUI. It's hard to find but as of August 2017 it's still available here.
A change was made by Microsoft and with the release of Windows 2008 R2 you can now configure PSOs via Active Directory Administrative Center (ADAC). To do so on your Domain Controller open ADAC and expand your domain. Then expand System and open the "Password Settings Container". Right click and select "New". On the "Create Password Settings" screen you can configure the password settings. In the "Directly Applies To" section you can select which Users and/or Groups to apply this policy to.
Child articles:
Back to top