Jump to content


Configuring Granular (Fine-Grained) Password Settings in Windows Server 2008 + video

7 replies to this topic

#1 mashti


    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38666 thanks
  • LocationActive Directory Inside

Posted 27 September 2010 - 02:49 PM

Part 1


In previous versions of Active Directory (AD) we had only one password and account lockout policy for the entire domain. Some companies had to use multiple domains to place different password policies on different users; others had to develop their own password filters or buy third party solutions. With Windows Server 2008 we have the option to specify different password policies for different users and groups “out-of-the-box”.

This first of two articles is a “walkthrough” on creating a password policy in addition to the usual one we have in the “Default Domain Policy” Group Policy placed on the domain level.

New in class

In short the new functionality, referred to as “Granular Password Settings” or “Fine-Grained Password Policy“, is based on the introduction of two new object classes in the AD schema: the “Password Settings Container” and “Password Setting” objects. These objects basically provide us the option to introduce multiple password policies into a single AD domain. But let us take a look at what else we need…
The tools and prerequisites

This is a quick view on the tools and prerequisites needed for creating additional password policies.


First of all the Active Directory domain functional level must be “Windows Server 2008”. This can be checked using Active Directory Users and Computers (ADUC) – Right click the domain > choose “Raise domain functional level” – the current domain functional level should read “Windows Server 2008” (below is a screenshot from the beta 3 version of Windows Server 2008 build 6001):

Posted Image
Figure 1

We will still have to use the Group Policy Management Console (GPMC) to set the default password policy for the entire domain (the “fallback” policy you could say). If you have forgotten how to set the default domain password and lockout settings, they can be found in GPMC on the domain level under “Default Domain Policy” > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy/Account Lockout Policy.

By the way, the GPMC is included with Windows Server 2008 (like with Windows Vista), but must be added as a “Feature” – choose “Add Feature” in Server Manager, select ‘Group Policy Management’ and after a few moments you are ‘Group Policy Ready’

The most important tool for this ‘exercise’ is actually a tool that most administrators have feared through the years – because whenever you have to use it it is normally when something bad has happened – well, I am referring to the ADSI Edit utility (adsiedit.msc). Most of the granular password policy settings are created and configured from within this tool. ADSI Edit is part of the standard Windows Server 2008 installation so you do not have to add it afterwards.

The steps

This is a quick view on the steps required to configure ‘Granular Password Settings’ in Windows Server 2008:

   1. Create a Password Settings Object (PSO) in the Password Settings Container (PSC) using ADSI Edit
   2. Configure the PSO options by completing the ‘primitive’ wizard within ADSI Edit
   3. Assign the PSO to a user account or a global security group
   4. Confirm that the settings actually applied

Now that we know what steps we have to take, let’s get going!

Let’s get started

First, let us fire up ADSI Edit by clicking Start > Run… > “adsiedit.msc” and click OK (or press Enter).

Right click the “ADSI Edit” root and select “Connect to…”

Posted Image
Figure 2

Select OK to choose the default options in the “Connection Settings” dialog:

Posted Image
Figure 3

In ADSI Edit you should now be able to expand the domain, expand the ‘System’ container and finally right click the new ‘Password Settings Container’ (PSC) and choose New > “Object...”.

Posted Image
Figure 4

You will now have to select a class for the new object, but you are given one choice only (sometimes it is nice not to have too many options, right?). Select msDS-PasswordSettings and click Next:

Posted Image
Figure 5

From now on a pretty basic “wizard” is started that guides us though the process of creating a Password Settings Object (PSO). We will have to specificy a value for each of the following 11 attributes. Type in the values as shown in the table below (be sure to type the ‘minus’ sign in front of values where it is required) or come up with your own.

Posted Image
Table 1

When all that typing is done you should see the following dialog – just click Finish.

Posted Image
Figure 6

Make it happen

Now the PSO is created and it should be visible below the PSC in both ADSI Edit and ADUC/Server Manager (just remember to enable “Advanced Features” in the View menu), it should look like this:

Posted Image
Figure 7

From this point all we have to do is to assign the new policy to a specific user, multiple users, a global security group, multiple global security groups or a combination of users and global security groups.

To do this, right click the PSO in ADUC (or ADSI Edit) and select Properties – click Filter and make sure you have the following options selected/de-selected:

Posted Image
Figure 8

If you cannot see the picture I can tell you that the following options are selected: “Mandatory”, “Optional”, “Constructed”, “Backlinks” and “System-only”. The “Show only attributes that have values” is NOT selected.

Now browse to msDS-PSOAppliesTo, select it and click Edit.

Posted Image
Figure 9
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.

Che Guevara

#2 mashti


    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38666 thanks
  • LocationActive Directory Inside

Posted 27 September 2010 - 02:50 PM

continue Part 1

In the “Multi-valued String Editor” insert the distinguished name of a user or a global security group in the “Value to add” field and click Add. You can add multiple distinguished names in this dialog – when done just click OK.

Posted Image
Figure 10

In the example above I have added a global security group named “Admins” (with the distinguished name of “CN=Admins,CN=Users,DC=Contoso,DC=Local”). Every user account that is a member of this group is now hit by the new “PassPolAdmins” password policy instead of the one defined in the Default Domain Policy. Cool, right!

At this point you might wonder what happens if the user is “hit” by multiple conflicting password policies. I will get back to this in detail in the next article in this series, but let me remind you we defined a ‘precedence’ value during the PSO creation.

Did you notice the change?

When you browsed around in ADUC just before, did you then notice the new “Attribute Editor” tab we now have on most objects (View > “Advanced Features” must be enabled)?

Posted Image
Figure 11

This is really cool because it enables administrator to view or edit lots of stuff which should normally be done within the ADSI Edit tool. With this tab we can take properties on the PSOs in the domain and modify the msDS-PSOAppliesTo attribute to easily set the password policy on a user or group (or move a user or group from that policy). Please notice that you cannot set the password policy from properties on the user or group objects – information about what policy applies to which users or groups is in other words set on the Password Settings Object itself!

Where can I see what policy wins?

It can be hard to determine what policy ‘wins’ for a specific user object (probably the one with the lowest cost AKA precedence value) – the Resultant Set of Policy (RSoP) you could say. But I am happy to tell you that Microsoft thought about this by introducing the msDS-ResultantPSO attribute on user objects (only).

Posted Image
Figure 12

This value determines what policy applies to the specific user (in my example a user named “Windows Admin”). This is in other word the “active” password and lockout policy for the selected user.

Both group and user objects have another new attribute, msDS-PSOApplied, which holds (in a multi-valued string) all the policies that the group or user is hit by - either directly or through group membership. In the example below the group called “Admins” is hit by 2 different password policies.

Posted Image
Figure 13

NB! If you cannot see the values mentioned here, be sure to set the “Attribute Editor” tabs filtering options to the ones described in the “Make it happen” section above.


We have now seen how to add a password and lockout policy in addition to the existing policy which is defined on the domain level by default.

To be honest I sometimes wonder why Microsoft was not able to make the procedure for this as easy as it is with for example Specops Password Policy (with Windows 200x AD)
where everything is handled within GPEDIT, but at least we have a free option built-in to Active Directory now. I guess Microsoft wants the ‘security group approach’ instead of the ‘OU approach’ – most likely based on requests from costumers out there.

It is just a matter of getting used to this new approach and I am sure we will see some easy-to-use tools and scripts within short time to make the described process even easier to complete. Despite the “nerdy” management of these policies I think it is going to be used a great deal out there – let’s hope so anyway!
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.

Che Guevara

#3 mashti


    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38666 thanks
  • LocationActive Directory Inside

Posted 27 September 2010 - 03:04 PM

Part 2

This last of two articles will give some useful background information about the granular password settings in Windows Server 2008. We will now deal with the new attributes on groups and user objects, the Password Settings Objects (PSO), the resultant PSO, design recommendations, Shadow Groups (SG) and much more…

Why would I want to do this?

We have now seen how to create PSOs and assign them to users and/or groups, but why do we need multiple password and account lockout policies you might ask? Well, there are many reason for doing this – one could be “hosting” scenarios where multiple companies are present in a single AD domain, another more common reason is where we need stricter settings to apply to a specific group of people with privileged accounts (like domain administrators, help desk personnel etc.).

Those privileged accounts can have a complexity requirement and a requirement of defining a minimum of 16 characters in their passwords and other, more limited accounts, can have more “user friendly” requirements - although I would recommend everyone to use passwords of that strength (more about this in a later article).

Who can hit what?

At the risk of repeating myself I must say this to make sure it is 100% clear. The new “multiple password policy” functionality in Windows Server 2008 (Codename “Longhorn”) allows us to set individual password policies and account lockout policies on user objects, interOrgPerson objects and global security groups.

Fine-grained password policies cannot be applied to an OU directly – now we must apply these policies to groups instead. Not any kind of group – it must be security groups set to the global scope. It’s possible to set the options/attributes on other groups; however it will not work as expected (the settings are ignored).

If we really want to handle password policies within the OU structure, the ‘Shadow Groups’ can be useful – see the section ‘Shadow Groups and how to script them’ later in this article.

By default only members of the “Domain Admins” group can set, create and delete fine-grained password policies – better known as Password Setting Objects (PSO). However, these permissions can be delegated and tweaked if required, but the default settings should be fine for most environments. To be more specific, only members of the Domain Admins group have the required ‘Create Child’ and ‘Delete Child’ permissions on the Password Settings Container (PSC) object.

To apply a PSO to a user or a group object, you must have ‘Write’ permissions on the PSO object – members of the Domain Admins group are the only ones with this permission by default. The “funny” thing is that you don’t have to have permissions on the user or group object itself, as these are set by a background directory process.

Take a look at those attributes

I just have to mention some of the attributes that make all of this possible.


Every PSO has a multi-valued attribute named msDS-PSOAppliesTo which is known as a ‘forward link’, linking to user or group objects. It can link to a single user, a single group, multiple users, multiple groups or multiple users and groups. These links are actually just the distinguished names (Eg. “CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local”) of the associated objects.

You might ask: What if we rename or move a user or group object (to another OU or container), will the PSOs “follow” the objects? Yes - the PSOs msDS-PSOAppliesTo attribute is automatically updated by the directory service in the background, to point to the new location (distinguished name) of the changed object.


The just mentioned msDS-PSOAppliesTo attribute on the PSOs can be edited as opposed to the ‘back link’ attribute msDS-PSOApplied which is present on user and group objects. The latter attribute is “view only” and handled by the directory service in the background.

The msDS-PSOApplied attribute contains a ‘back link’ to the PSO/PSOs pointing at its parent object – as users and groups can have multiple PSOs applied to them this attribute is multi-valued too.


The msDS-ResultantPSO attribute is present on user objects only. It contains a calculated value, also referred to as the “Resultant Set of Policy” (RSoP). This is a link to the single “lucky” PSO that is active on the specific user object. This value is calculated by the directory service process in the background from the rules mentioned in the next section of this article (“The Design”).

You might ask: When is the password policy active on a user who is added to a group? As soon as a user is added to the group the resultant PSO is also calculated for the user object by the directory service. It is the same story if you remove a user account from a group - the change takes effect immediately.


The msDS-PasswordSettingsPrecedence attribute is present on the PSO objects. A lower value for this attribute indicates that the PSO has a higher priority. This attribute is used when multiple PSOs are applied to a user object – i.e. the lowest “cost” is chosen . If you assign a unique precedence value to each of your PSOs in the domain, it will always be easy to determine the effective password policy for a certain user object.

The design

Before implementing multiple password policies in the domain it is recommended to get an overview of what policies are needed and to finish the overall design of those policies and their interaction.

You can have multiple policies assigned to a single user, directly or through group memberships (even nested security groups are addressed), but only one PSO can be effective for a certain user object at any given time, and password or lockout settings cannot be “merged” like with Group Policies – it is one or the other policy that takes effect.

Therefore we need some rules and a priority calculation when multiple PSOs are present for a user.

The simple rules…
The resultant PSO is determined as follows:

   1. A PSO that is linked directly to the user object will take effect unless multiple PSOs are linked directly to the user object. If more than one PSO is linked, the PSO with the lowest precedence value (msDS-PasswordSettingsPrecedence) is the resultant PSO. If the system should spot two or more PSOs applied directly to a given user, all with the exact same msDS-PasswordSettingsPrecedence value, the PSO with the smallest Global Unique Identifier (GUID) is applied.
   2. If no PSOs are linked to the user object, the global security group memberships of the user are taken into consideration. If the user is a member of multiple security groups with different PSOs applied, the PSO with the lowest precedence value is the resultant PSO. If the system should spot two or more PSOs applied by group membership to a given user, all with the exact same msDS-PasswordSettingsPrecedence value, the PSO with the smallest GUID is applied.

If no PSO is obtained from conditions 1 and 2, the password and lockout settings from the “Default Domain Policy” are applied, just like it was with earlier versions of Active Directory (AD) environments.

So, to make a long story short: PSOs set on user objects will win over PSOs set on group objects and the lower precedence value will win over the higher – if that “fails” the result is based on GUID numbers – and if nothing applies we are back to where we started: The “Default Domain Policy”!

As more general recommendations I will mention these:

The ‘Description’ field can be used to specify the password and lockout settings that are enabled in the PSO. Use it for a quick ‘wrap-up’ of the PSO configuration and intended use.

Create a naming convention for PSOs like you have for other AD objects etc.

Assign PSOs to groups, instead of directly on user objects, for better overview and easier manageability.

Assign a unique precedence value to each of the PSOs in your domain, it will then be much easier to determine the effective password policy for a certain user object.

The Default Deny All rule

Well, I know this might not be a popular thing to say, but I would recommend you set the password settings contained in the “Default Domain Policy” to a very high (almost ‘annoying’) level of security. This is because you – or somebody else – might “forget” to include a user in one of the password security groups. In that case the user accounts password policy will “fallback” to the one defined in this default policy set on the domain level.

Look at the security policy in the Default Domain Policy as the “Default Deny All” rule in a firewall – if no specific rule/policy is available for the user (or one of the groups of which he is a member) then we should place a very strict policy on the user’s ‘head’. The user will probably call help desk to get this fixed ASAP - if we give the user a very relaxed password policy instead he/she will, in most cases, never complain.

Another way to do this would be to set a granular password policy on the “Domain Users” group with the lowest priority used - but again, at some point an account might “slip” out of this group for some reason… My choice is definitely the Default Deny All rule – as always!

Shadow groups and how to script them

If you have never heard about “Shadow Groups”, do not worry – neither had I two months ago. A Shadow Group (SG) is a security group (in this case a Global security group) that contains the objects within a given OU as members. A SG is a security group that is “logically” mapped to an OU you could say.

For instance you might have an OU, “OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local”, with the user accounts for the entire sales department – a SG would be a group that matched that content 100%. For password policies this can be a really good thing if we want the password policies to “follow” the OU structure “virtually”, instead of following the Security Group structure.

You can probably imagine that this would mean a great deal of work if we had to update the SGs manually every hour or so – that is why I have written a small and simple VBS script to automate this process by using a scheduled task.

The script collects the user accounts from a specific OU - specified as an argument to the script – and places those into a dictionary object. The script then collects the users within a specific group - specified as an argument to the script - and places those into another dictionary object. By comparing those dictionaries, the script adds or removes users from the “shadows group”. The script is ‘designed’ to be scheduled as a task and should be used with the following syntax: ShadowGroup.vbs "Target OU" "Shadow Group"


ShadowGroup.vbs "OU=Test,DC=Contoso,DC=Local" "CN=Shadow,OU=Test,DC=Contoso,DC=Local"

The script can be downloaded here,
but use in a production environment is at your own risk. It is recommended to put in some error handling routines and maybe reporting functionality. Also support for sublevel OUs would be a good idea to implement. I might provide such a script later on, but so far we have the basic functionality included.


It is actually possible to script the creation and modification of granular password policies and assigning those policies to specific users or groups. However, this article will not deal with these possibilities in detail.

We can use the good old LDIFDE tool and of course, the new Sheriff in town, Mr. PowerShell. Windows PowerShell is included with Windows Server 2008 and must be added as a “Feature” – choose “Add Feature” in the new and shiny Server Manager, select Windows PowerShell and after a few moments you are ‘PowerShell Ready’

I will recommend you trying out the Quest AD Cmdlets
and to check out PowerGui.org.

A free command line tool, PSOmgr,
already exists from Joeware.
With this tool you can manage Password Settings Objects in Windows Server 2008 very easily, eg. display the applied policies and the effective policy of a given user, display the PSOs in the domain/forest, add or remove a user from a PSO, create/rename/delete/modify PSOs and much more…

External links

AD DS: Fine-Grained Password Policies

Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration

Granular Password Setting - Video

Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.

Che Guevara

Thanked by 2 Members:
pulisysadmin , Dreamfall

#4 Krishnendu


    Advanced Member

  • Members
  • PipPipPip
  • 55 posts
  • 52 thanks
  • LocationINDIA

Posted 19 April 2011 - 02:31 PM

Very very very nice. Fine Grain password and lockout policy is one major development on server 2008.

#5 AlanRichmond


    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 0 thanks

Posted 18 May 2011 - 11:44 PM

Does anyone have a copy of the http://www.heidelbergit.dk/Artikler/ShadowGroups.txt script.

This link is no longer available, nor it seems is the author


#6 CyCoe


    Advanced Member

  • Veteran
  • PipPipPip
  • 312 posts
  • 11055 thanks

Posted 19 May 2011 - 09:02 AM

I would recomend to use SpecOps Password Policy Basic
Hidden Content
You'll be able to see the hidden content once you press the thanks button.

No need to learn somesthing, just click :)
Posted Image

Do not post useless "thank you" post.
Please use the "Thanks" button as shown in the announcements http://certcollection.org/forum/topic/99091-new-feature-added/
The only way to see the hidden content in our shares section is pressing the 'Thanks' button!

Thanked by 5 Members:
puli.sysadmin , Danchez , pakkiraja , Ahmet2009 , kumar4tsm

#7 thinmin


    Advanced Member

  • Members
  • PipPipPip
  • 261 posts
  • 6404 thanks

Posted 19 May 2011 - 02:00 PM

View PostAlanRichmond, on 18 May 2011 - 11:44 PM, said:

Does anyone have a copy of the http://www.heidelbergit.dk/Artikler/ShadowGroups.txt script.

This link is no longer available, nor it seems is the author


Pls follow the forum rules.
Use [Req] for request.
Use [Offer] for offer.
Use search option before you post.

Now you joined the top IT Community. It is time to join the number 1 team


Thanked by 1 Member:

#8 Ahmet2009



  • Members
  • PipPip
  • 48 posts
  • 40 thanks

Posted 26 May 2011 - 05:06 PM

Thank you

Thanked by 1 Member:

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users




Test Providers

Site Info

Go to top