Fine-Grained Password Policy in Windows Server 2008/2008R2


Recently, I have seen that some administrators afraid of using Fine-Grained Password Policy.It looks like the main reason is they do not know how to set up and how to manage it. I will try to show you some easy steps to understand that and implement in your Active Directory environment.

First of all, if you wish to implement Fine-Grained Password Policy (FGPP) in your environment, your Domain Functional Level must operate at Windows Server 2008 mode. That means, all of your Domain Controllers in a domains must be ran at least on Windows Server 2008. No previous operating systems may be used for DCs. Of course, all the rest domain member servers may be ran on earlier OS versions.

For more details about Domain Functional Level, please read my article on this blog.

OK, so what is FGPP and why we want to use it? As you remember in Windows 2000 Server and Windows Server 2003 we were able only to use single password policy defined at domain level over GPO. There were no possibility to use more than one domain password policy using group policies. When some department in our enterprise required another password policy, we needed to decide if we want to:

  • convince it to use the standard password policy 🙂
  • configure child domain and migrate their objects
  • use 3rd party tools

For more details about Default Domain Password policy, please check an article on my blog for that.

This situation did not change in Windows Server 2008, you can still use only one domain password policy configured in GPO. However, Microsoft introduced new feature to define additional password policies. The policy allows you to define separate password settings for user of group of users.

Important! Fine-Grained Password Policy may be only assigned to user or security global group not to domain or OU

When your DFL is set up at appropriate level, you can start using Fine-Grained Password Policy feature. What do you need to know about this kind of Password Settings Object (PSO) before you will set it up:

  • you can apply it only to user or security global group
  • you can set it up using ADSI Edit
  • you can set it up using PowerShell module for Active Directory
  • you need to use dsget command to verify if policy is applied
  • you can use PowerShell to manage PSO
  • only one password set applies to user or group

Using Fine-Grained Password policy, you overwrite default domain policy for user or group of users. However, you need to know that you may apply as many FGPPs as you wish but the only one will be applied. There are few important things to know about password policy precedence:

  • when applied more than one to a group then PSO with the lowest precedence index is applied
  • when applied more than one to a user then PSO with the lowest precedence index is applied
  • when applied more than one to a user or a group then PSO on user level is applied
  • when user is a member of few groups with PSO assigned then policy with the lowest precedence index is applied

Now, when we know those things, we can start creating our first Fine-Grained Password Policy.


ADSI Edit allows you to use GUI method for PSO creation. To start the process, run ADSI Edit from “Administrative Tools” or type in run box: adsiedit.msc

Running ADSIEdit console

When you ran that console, you need to connect to Deafult Naming Context where those objects are stored. To do that, click on root “ADSI Edit” node in a console by right mouse button and choose “Connect to

Connecting to Default Naming Context

Now, in “Connection Settings” window please ensure if in “Select a well known Naming Context area you have pointed to Default Naming Context

Connecting to Default Naming Context

When you are connected to that Naming Context, you need to navigate to a container where you can create PSO. The location of this container is in

CN=Password Settings Container,CN=System,DC=domain,DC=local

Below you can see that container location in ADSI Edit console

PSO container location

In this place you need to create new object by clicking right mouse button and selecting “New -> object”

Creating new Fine-Grained Password Policy

Create object which is responsible for password settings “msDS-PasswordSettings“. From now, you are defining new password policy. Proceed below steps to successfully finish PSO creation process.

Selecting object class

At this step, you need to define Fine-Grained Password Policy name which would be easy to identify by you when you start reviewing PSO list

Creating new PSO object

Now, you need to set up integer value of precedence index. Remember, when any PSO would be in conflict then password policy with the lowest precedence index is being applied

Creating new PSO object

This time, you need to specify if you want to use reversible encryption for passwords. This will store password in plain text, so this is vulnerability for the environment. Do not use this option if any of your legacy application requires that. For this setting you can only use one of two possibilities for boolean variable:

  • true to enable reversible encryption policy
  • false to disable reversible encryption policy

Creating new PSO object

Define how many previous passwords are remembered and user cannot re-use them. This value should be an integer number

Creating new PSO object

OK, at this time, you need to define if user’s password must be complex using 3 out of 4 character categories. When you use true value then, password must meet the complexity using 3 characters group out of 4 available:

  • small letters [a-z]
  • capital letters [A-Z]
  • digits [0-9]
  • special characters [!@#$%^&*()]

in case that yo do not want to force users using complex passwords, you need to put false value in a form. In this example, we would like to use complex passwords

Creating new PSO object

User’s password requires minimum number of characters needed to build good and invulnerable password. You need to define the lowest number of characters to build the password by user. This value is an integer number

Creating new PSO object

Really important part of each password policy is setting for the minimum password age. That means, when user is able to change his/her password after the latest change. When you set this up to short time or disable it, user may change his/her password few times and then he/she is able to use that previous password(s) again. The important part during setting up PSO is to remember that this setting uses non integer variable! Expected value is duration which defines a time in format



  • d means, how many days
  • hh means, how many hours
  • mm means, how many minutes
  • ss means, how many seconds

an example duration for password which may be changed again after 3 days


Creating new PSO object

the next setting determine when user is forced to change the current password. You need to set up time after which password is required to change. This value is also in the same format as the previous one, so you need to use duration format as this is shown in the above step

Creating new PSO object

And now, another part of setting password policy. You need to decide if you wish to enable account lockout or not. However, this is good practice to enable account lockout policy to prevent users guessing password of other users in your environment or prevent hackers from guessing password of your users. Just define integer value for the policy and after entered number of failed logon attempts, the account is being blocked

Creating new PSO object

When you defined after how many failed logon attempts, user account is locked you are able to define 2 other policies related with the previous one. Lockout Observation Window in which you define when user may try to log on once again to the system. After that time, user is able to try once again (but only one chance) log on to the system. If he/she remembers a password and account was locked out by mistake, the next try would be successful. If user does not remember the password, after the next wrong attempt, the account would be locked again for time specified in Lockout Observation Window. This option allows an administrator to tell the users that if they remember password but they locked the account by mistake, they need to wait specified time and try once again. In other case, they should request a password reset. For that setting you need to use again duration variable format like for minimum and maximum password age.

Creating new PSO object

The second policy related with account lockout is Lockout Durationwhich determines the time when user account is completely unlocked. Then user has again defined number of tries to log on to the system. As for the previous setting, it also uses duration format to define time

Creating new PSO object

That was the last setting in PSO wizard. However, remember that when you close it by clicking on “Finish” button, you have only create password policy but it is not applied to any group or user. If you wish to define that at this step, click on “More Attributes” button and from “Select a property to view” drop down box choose “msDS-PSOAppliesTo

Creating new PSO object

Creating new PSO object

When you choose that attribute, you need to define distinguished name of an object to which you want to apply policy. This requires from you to know that DN name to put it in that field in format:

CN=Object Name,OU=OU Location,DC=domain,DC=local

and press “Add” button to add the object to password policy

Creating new PSO object

You can see all objects assigned to PSO in the “Value(s)” list

Creating new PSO object

Above step in PSO wizard requires from you object’s DN to know. What if you do not know it or this DN is really long? You may simply finish a wizard without defining value for msDS-PSOAppliesToattribute. This may be done later in some short and more convenient way. Just take a look for below steps.

When you finish a wizard, you will see new password policy in a selected container. Just edit it by double click on it in ADSI Edit window.

Edit existing PSO

In the “Attribute Editor” list search for msDS-PSOAppliesToattribute and click “Edit” button

Edit existing PSO

Now, you have 2 options for object(s) assigning. Classic window for distinguished name of an object

Edit existing PSO

Edit existing PSO

or just use more familiar option to search an object from AD

Edit existing PSO

Edit existing PSO

OK, when we have created granular password policy and we applied it to some object, how to see if the user is really using that policy? You can use for that dsget command or dsquery and dsget commands combination. Let’s see, how to check if PSO is applied to a user name iSiek

dsquery user -samid iSiek | dsget user -effectivepso

After running this query, you will see information about used PSO policy. If result is empty then you can be sure that user has no Fine-Grained Password Policy assigned and he/she uses default domain password policy

Effective password policy applied to the user

This is working fine as you can see! If you really need different password policies in your environment, I really encourage you to use Fine-Grained Password policy feature as it is really great feature!

PowerShell module for Active Directory

As we already know something more about Fine-Grained Password policy requirements, now we can check how to simply create and apply PSO to an object. For that we need to use PowerShell module for Active Directory. To initiate it run in PowerShell window

Import-Module ActiveDirectory

PowerShell – importing AD module

and wait for cmd-lets to be imported. Now, you can use some PowerShell cmd-lets to manage PSO, let’s see their names. Type in PS window

Get-Help *-ADFine*

Getting cmd-lets for Fine-Grained Password Policy

To create new granular password policy we need to use New-ADFineGrainedPasswordPolicy cmd-let. We need to define all interesting us values as we did it using ADSI Edit. When you skip any value then default settings for that value is being used.

Let’s see how to create another PSO using the same values as in the previous example but over PowerShell cmd-let

New-ADFineGrainedPasswordPolicy -Name it-security-PSO-02 `
-DisplayName it-security-PSO-02 `
-Precedence 200 `
-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

PowerShell – PSO creation

PSO list

As you can see, PowerShell created new PSO but it is not assigned to any object. We need to use another cmd-let to accomplish that. This cmd-let is Add-ADFineGrainedPasswordPolicySubject

This time, I will assign granular password policy to the user directly.

Add-ADFineGrainedPasswordPolicySubject -Identity it-security-PSO-02 -Subjects iSiek

Assigning PSO to an object

Now, it’s time to verify if PSO is applied to a user. For that you need to use Get-ADFineGrainedPasswordPolicy cmd-let

Get-ADFineGrainedPasswordPolicy -Filter { name -like 'it-security-PSO-02' }

PSO applies to

and that’s all about configuring and setting up Fine-Grained Password Policy objects. You may also check the rest cmd-lets to modify and remove PSO objects.

Author: Krzysztof Pytko


6 responses to “Fine-Grained Password Policy in Windows Server 2008/2008R2”

  1. Matt says :

    Hi Krzysztof,

    I happened to come across your blog and thought I’d just say that I think you’re doing a great job on sharing helpful information on Active Directory. Nice work.

    By the way, thought you might like to know that the Fine Grained Password Policy feature was originally designed by our CEO, during his Microsoft years, and I’m told that it was subsequently changed a bit due to time constraints.

    If you’re into Active Directory Security, you’re also welcome to join the Active Directory Security Professionals Group, which consists over 1500 members from over 100 countries. Its free to join, and could be helpful for you too.

    Best wishes,

    • iSiek says :

      Hi Matt,

      thank you! It means a lot for me. I will try to keep going in this direction.
      I would check also that security blog and who knows, maybe I will join 🙂


  2. Ali says :

    I tried the guidelines . After implementing the powershell query as: dsquery user -samid ali | dsget user -effectivepso
    it displays :

    dsget succeeded
    but alteration has not applied. We are using win2008 R2 domain functional level .
    Any suggestions ?

    • iSiek says :

      Hmm, PowerShell is another cmd-let. DS tools are old fashioned command-line tools.
      Have you tried with elevated command prompt before executing dsquery ?

      Mostly, this is related to that problem.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.