Group Policy - Password and Account Lockout Policies

This article was also published on the Microsoft TechNet Blog CZ/SK under the title Password and Account Lockout Policies using Group Policy.

This area is referred to in English as the Password and Account Lockout Policy. The Password Policy allows us to specify password parameters, such as the minimum number of characters, whether the password must be complex, whether passwords must be changed at regular intervals (minimum and maximum password age), whether and how many previous passwords are remembered (which then cannot be set again).

A complex password in this case means that it must not contain part of the user's name and must contain characters from at least three of the four possible groups:

• uppercase letters (A-Z)
• lowercase letters (a-z)
• digits (0-9)
• special (non-alphanumeric) characters (e.g. *#,.@%)

In Group Policy, the password policy settings are located at Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy. The settings in this policy take effect when the password is changed. This means that when we change the policy settings, nothing changes for the user until they change their password, then they must follow these parameters.

The password change can be enforced by the interval (maximum password age) or by setting the User must change password at next logon attribute on the account. If the Password never expires attribute is set on the user account, the password age does not apply to this account (there is no obligation to change the password, even if the policy is set). It is not possible to set both User must change password at next logon and Password never expires at the same time. So if we set a password policy and want to have passwords according to it, we have only one option. We set the User must change password at next logon attribute on the accounts and turn off (just to be sure) Password never expires. We can do this easily using PowerShell, for example:

Get-ADUser -Filter * -SearchBase "OU=Company,DC=company,DC=local" | Set-ADUser -PasswordNeverExpires $false
Get-ADUser -Filter * -SearchBase "OU=Company,DC=company,DC=local" | Set-ADUser -ChangePasswordAtLogon $true 

The Account Lockout Policy determines whether and after how many incorrect password attempts the account will be locked, whether it will automatically unlock after a specified time, and after what time the incorrect password counter will reset. In Group Policy, the account lockout policy settings are located at Computer Configuration/Windows Settings/Security Settings/Account Policies/Account Lockout Policy.

Password Policy for Domain Accounts Before Windows Server 2008

If our domain is lower than Windows Server 2008, we can only have one password policy for one domain. This means that the same rules apply to all accounts in the domain. In general, this is because there can only be one password policy for each account database. Active Directory is one database, and each computer has its own local database for local accounts. So for each computer, there can be a different policy for local accounts, and then there can only be one common policy for the domain and domain accounts in it. It can be worked around, but only in a complicated way, such as by creating multiple domains.

By default, when the first DC is installed, two GPOs are created:

• Default Domain Policy GPO - linked to the root of the domain, main settings for the domain including the password policy
• Default Domain Controller Policy GPO - linked to the Domain Controllers OU, initial security settings for DCs

Note: The recommended solution is not to change the settings of these two GPOs, but to create a new GPO in the same location and give it a higher priority. This way, we can quickly revert to the original settings in case of problems (just disable the new GPO).

The domain password policy is normally part of the Default Domain Policy, but this is not absolutely necessary. We can use any policy (create a new one) where we define the password policy rules for domain accounts, but we must link this policy to the root container of the domain. And its values must not be overwritten by any other policy in this location, in other words, we must set the highest priority for this policy.

Local Account Password Policy

The password policy for local accounts on the computer can be defined either locally using the Local Group Polici Editor or centrally by a domain policy. When we create a password policy and link it to a container with computers, this setting will not apply to domain accounts, but to local accounts on the given computers.

Additional Policies for Domain Accounts on Windows Server 2008

If we have a Windows Server 2008 domain functional level, we can use Fine-Grained Password Policy (FGPP), which allows us to define multiple password policies for different groups of domain accounts. However, we still create the basic password policy (default) the same way and link it to the root of the domain.

If we want to create an additional password policy and apply it to certain accounts, we need to use FGPP. The AD schema is extended with two objects, Password Settings Container and Password Setting, which are used in this case. So we can't use the standard methods and the Group Policy Management Console tool, but we have to use either ADSI Edit (adsiedit.msc) or PowerShell and the Active Directory module (my preferred method).

The procedure is as follows: first, we create a Password Settings Object (PSO) inside the Password Settings Container, and set the policy parameters on it. Then we apply the PSO to a user or a security group (global security group). We cannot apply the PSO to a computer or an organizational unit (OU).

To summarize, Microsoft finally added the ability to create multiple password policies in the domain. Unfortunately, it didn't do it in a standard way, so we have to create additional policies in a completely different way. Moreover, it also changed the fact that we apply standard policies to an OU (or domain or site), but the PSO is applied to a security group or user (I'm not saying this is bad).

Creating a PSO Using ADSI Edit

Just a brief information on how we can use ADSI Edit.

• using adsiedit.msc, we connect to the domain (under an account with AD permissions - Domain Admin) to the Default naming context
• expand CN=Password Settings Container,CN=System,DC=company,DC=local
• right-click and choose New - Object from the context menu
• select msDS-PasswordSettings and Next
• now we go through a simple wizard, where we fill in 11 required attributes

The MS description, which contains details on the individual attributes, is in the article AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide.

Assigning a PSO Using ADUC

The created PSO objects are also visible using Active Directory Users and Computers (ADUC), if we have the View - Advanced Features menu set. And it is in ADUC that we will assign policies to users or groups (we can of course do this in ADSI Edit as well).

• expand our domain, the System container and the Password Settings Container
• open the PSO (double-click)
• switch to the Attribute Editor tab
• find the msDS-PSOAppliesTo value and choose Edit
• here we add the required users or groups

If we want to find out if and which PSO is applied to a user, we open the user account in ADUC and switch to the Attribute Editor tab. If we don't have the constructed attributes displayed, we click on Filter and check Constructed. Then we can find the msDS-ResultantPSO attribute, which contains the name of the applied (winning) policy (PSO). We can also look at the msDS-PSOApplied attribute, which lists all the applied PSOs (this attribute is also visible for groups).

Creating and Assigning a PSO Using PowerShell

It's a matter of taste, but using PowerShell seems to me a better method. We need the ActiveDirectory module for this, which is part of the Remote Server Administration Tools.

To create a PSO, we'll use the New-ADFineGrainedPasswordPolicy cmdlet. The individual parameters are understandable from the name. However, there is an important difference compared to the standard policy, and that is that we cannot set the MaxPasswordAge value to 0 to have the password never expire. If we enter zero in the cmdlet, we get an error that doesn't seem very informative.

New-ADFineGrainedPasswordPolicy : The modification was not permitted for security reasons

The solution is either to set Password never expires on the accounts or set MaxPasswordAge to the maximum value of 10675199.00:00:00, which is really high. Here are two examples of creating a PSO.

New-ADFineGrainedPasswordPolicy -Name "NameOfPSO" -DisplayName "Domain Users PSO" -Description "The Domain Users Password Policy" -Precedence 500 -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 10 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "1.00:00:00" -ComplexityEnabled $true -MinPasswordLength 8 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false
New-ADFineGrainedPasswordPolicy -Name "PSO2" -Precedence 10 -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 3 -MaxPasswordAge "10675199.00:00:00" -MinPasswordAge "0.00:00:00" -ComplexityEnabled $true -MinPasswordLength 12 -PasswordHistoryCount 0 -ReversibleEncryptionEnabled $false

I also ran into a problem that sometimes PowerShell didn't work on the domain controller and I got an error.

New-ADFineGrainedPasswordPolicy : Access is denied

Using PowerShell, we can also assign a PSO to a user/group with a simple command.

Add-ADFineGrainedPasswordPolicySubject NameOfPSO -Subjects 'Domain Users'

Changing values in a PSO.

Set-ADFineGrainedPasswordPolicy "NameOfPSO" -MinPasswordLength 8 -PasswordHistoryCount 24

Deleting a PSO.

Remove-ADFineGrainedPasswordPolicy -Identity NameOfPSO

Removing a PSO assignment from a user/group.

Remove-ADFineGrainedPasswordPolicySubject NameOfPSO -Subjects User1

Listing all PSOs.

Get-ADFineGrainedPasswordPolicy -Filter 'Name -like "*"' | FT Name,Precedence,MinPasswordLength -AutoSize

Viewing details of a single PSO.

Get-ADFineGrainedPasswordPolicy NameOfPSO -Properties *

Which PSO applies to a specific user.

Get-ADUserResultantPasswordPolicy User1

The following command is also interesting, as it displays the default password policy for the current (logged in) user.

Get-ADDefaultDomainPasswordPolicy