Fine-Grained Password Policy Best Practices

Russell Smith by   07.11.2019   General

Password and account lockout policies in Active Directory needn’t be all or nothing. In this article, I’ll explain how to set password and account lockout policies for specific groups of users and some best practices you should follow in the process.

Active Directory Account Policies

Active Directory (AD) domains are configured by default with password and account lockout policies that apply to all user accounts in the domain. Each domain has a Group Policy Object (GPO) called Default Domain Policy where you can set password, account lockout, and Kerberos policies under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies. Account policies are the only settings that you should modify in the Default Domain Policy GPO.

Figure1

Password policies include the ability to enforce password history, set a minimum and maximum password age, password length, and more. Account lockout policies define the account lockout duration and the account lockout threshold, i.e. how many failed login attempts are allowed before accounts are locked out.

Fine-Grained Password Policy

AD supports one set of password and account lockout policies for a domain. Before Windows Server 2008, if you wanted to apply different password and account lockout policies to users, you had to set up a separate domain for them. For example, it’s common that organizations prefer to apply stricter password policies to accounts that have privileged access to AD because they are more likely to be targeted due to the high level of access they have. But strict password and account lockout policies that might be applied to privileged domain accounts are impractical for standard employees because they create too much inconvenience.

Beginning in Windows Server 2008, you can override the default password and account lockout policies in a domain using Fine-Grained Password Policies (FGPP). To use FGPPs, your domain must be at the Windows Server 2008 domain-functional level or higher. Don’t forget that raising the domain functional level is a one-way process.

Password Settings Objects

Unlike the default password and account lockout domain policies, FGPPs are set in password settings objects (PSO) in AD and not using Group Policy. There are two main ways you can configure PSOs: using the Active Directory Administrative Center (ADAC) or using PowerShell. You must be a domain admin or have permissions delegated to you before you can create or change PSOs.

In ADAC, navigate to the Password Settings container under System and create a new PSO. To navigate to this container, you must switch to Tree View using the icon on the left. Once you’ve configured the password and account lockout policy settings for the PSO, apply it to one or more global groups.

Figure2

Or use the New-ADFineGrainedPasswordPolicy PowerShell cmdlet to create a new PSO.

New-ADFineGrainedPasswordPolicy -Name administrators1 -DisplayName lepide_admins -Precedence 100 -ComplexityEnabled $true -ReversibleEncryptionEnabled $false -PasswordHistoryCount 10 -MinPasswordLength 8 -MinPasswordAge 3.00:00:00 -MaxPasswordAge 30.00:00:00 -LockoutThreshold 3 -LockoutObservationWindow 0.00:25:00 -LockoutDuration 0.00:30:00

And then apply the new PSO using Add-ADFineGrainedPasswordPolicySubject:

Add-ADFineGrainedPasswordPolicySubject -Identity lepide_admins -Subjects ‘Secure Admins’

Best Practices

When implementing FGPPs in your organization, there are several things to think about before creating and applying FGPPs.

  1. Each PSO must have a precedence index number. PSOs with a higher precedence index, like 1, take priority over those with a lower precedence index, like 10.
  2. PSOs can be applied to users and groups. When possible, apply PSOs to groups.
  3. Understand PSO precedence. While PSOs can be applied to multiple users and groups, only one PSO ever applies to a user account. The PSO with the highest precedence index, i.e. closest to 1, will apply. The msDS-ResultantPSO attribute in AD exposes the resultant PSO for a user object if you want to check it. PSOs linked to user accounts always take precedence over those linked to groups.
  4. Make sure that all PSOs have a unique precedence index number. If two PSOs have the same precedence index number, the PSO with the lowest GUID is applied.
  5. If you want to apply a PSO to all the users in an Organizational Unit (OU), you will need to create a group that contains all the members of the OU and apply the PSO to the group. If the users in the OU change, you must update the group membership.
  6. Use password and account lockout policy settings in the Default Domain Policy GPO for most users and create PSOs for smaller specific groups of users.
  7. Give PSOs meaningful names.

Overcoming a Lack of Visibility

If you’re struggling to get visibility over password resets and the cause of account lockouts, it might be indicative of a wider problem with Active Directory visibility. You may need to consider deploying an Active Directory auditing solution like LepideAuditor for Active Directory to ensure you are continuously and proactively tracking changes to your AD. This will help you get to grips with whether your Active Directory is secure and compliant. Start your 15-day free trial today.

If you liked this, you might also like...