Windows Server ‘Longhorn’: Granular Password Settings

I recently got permissions to blog about some of the features which are not as well known in the next version of Microsofts Server Operating System: Windows Server “Longhorn”. So let’s get started. One of them is that in Longhorn, you are not limited to implement a single Set of Password Settings to the whole domain (and therefor implementing different domains if you need different Password Settings), you are able to apply Password Settings on a Group and User basis. This is really great – I’ve had multiple companies who – for example – wanted to implement different password policies for administrative accounts.

After migrating to Windows Server “Longhorn” on their DCs, they are able to incorporate this feature.

For those of you, who wanted to implement it using OUs or GPOs, read the “appendix” [;)]

Which is important – this feature is available to you today – if you have MSDN or if you are a Betatester you already have access to the February CTP (IDX02) which is providing you with that feature, so you are able to test it (don’t implement Windows Server “Longhorn” in Beta in your production until being advised by Microsoft in a TAP-Program).

You are able to configure the Password Settings and Account Settings like in Group Policies, but on a granular level.
So how do you get it?

The basic concept is, that there’s a new object in Active Directory – the “Password Settings Object” which it’s LDAP-Name msDS-PasswordSettings. For a new set of Password Settings – you simply create one of those objects underneath the container “cn=Password Settings, cn=System, dc=example, dc=com“. You can do this using adsiedit.msc and you’ll have to fill in the mandatory attributes, which are listed in the following table:


GPO Branch



Password Setting

This is just a virtual number you can make up (make sure you leave some space in the numbering for future use) which defines which Password Settings are taking effect if mulitple apply to the same object (user or group, but settings on the user will always precendence settings on the group).
This will usually reflect on the “level” of the settings object, e.g. if you have stronger settings they have a lower value, if you have higher settings you’ll probably assing a higher precedence to them.


Password Setting

This attribute is boolean and defines if you want to store the passwords of the accounts (to whom the Password Settings Object applies) in reversible encryption or not. The default and best practice is “FALSE”


Password Setting

This setting defines how many old passwords the user cannot reuse again (to prevent the user from changing the password back and forward to the same one, or changing it multiple times until he’s able to reuse his old password).
The domain default is not to allow the last 24 passwords of that user.


Password Setting

This attribute is a boolean again, and defines if the password needs to be complex (does have at least three of the following character sets applied: lower letters, captial letters, numbers, symbols, unicode characters).
The domain default and best practice would  be to turn it on (TRUE).


Password Setting

This attribute defines the minimum lenght of a Password in characters. The domain default would be 7 characters long.


Password Setting

Also msDS-MinimumPasswordAge does just what it’s name suggests – defining the minimum age for Passwords. Minimum age is necessary to prevent a user changing his password x-times on the same day until exceeding the Password History back to the same value than before.
This is a negative number which you can compile/decompile using the scripts at…. as a guideline.
(domain default: 1 day = -864000000000)


Password Setting

And this is just the opposite and defines when you have to change you password. Also a negative number as above.
(domain default: 42 days = -36288000000000)


Account Lockout

Defines after how many failed attempts entering a password the user-object will be locked.
(domain default: 0 = don’t lockout accounts after invalid passwords)


Account Lockout

After which time should the “bad password counter” been reset?
(domain default: 6 min = -18000000000)


Account Lockout

How long should a password being locked?
(domain default: 6 min = -18000000000)

Afterwards you just need to link the new Password Settings Object to a group or user-account. You can only link this to global groups, so make sure to verify the group scope first. To link the PSO to a global group or user you just need to add the distinguished-name (e.g. “cn=my group, ou=corparate groups, dc=example, dc=com”) of the user or group in the attribute msDS-PSOAppliesTo of the Password Settings Object which you want to apply to the user or group. You can even prove it afterwards trying to change the (test)account by just resetting the password as Administrator.

So this is one of the great features coming with Windows Server “Longhorn” – I’m very excited about it!



How today’s password policies are implemented is actually not really through Policies. Actually a policy which is linked to the domain-head (the domain object in Active Directory, or the symbol which reflect the domain in Active Directory-Users and -Computers and in other interfaces) will be written to attributes of the domain-head, and those are the only settings which apply to any domain accounts. Everything which is configured in GPOs and linked to OUs is just applying to the computer accounts underneath that OU, and therefore to the local user accounts underneath (not user accounts). So if the Password Settings would be applied to OUs and GPOs it would be a bigger design change, and I guess you’d prefer to get the feature with the next Version than whenever [;)]

3 Responses

  • What a pity! To me it seems they just added complexity and missed the chance to add security. Why not implement sophisticated filters that check newly created passwords against a more complete set of criteria – such as dictionaries (a simple yet powerful way to avoid trivial and standard passwords) and all-too-simple variations of common passwords? The filtering functions you describe still allow trash passwords like “aaaaa1!” or the like.

    So we still have to go for common password filters. I hope at least they did not cut the interfaces to do that.

    Somewhat disappointed, Nils

  • Hi Nils,

    while you are right that it would be nice to allow additional settings (grade of complexity, dictionary compares,..) I still believe that this is going in the right direction. What we get for now is less domains for password policy reasons, and a more granular way to decide which users should have which settings when it comes to lockouts and length. This is handy to differenciate regular users, admins, service accounts,…

    If you want to add additional criteria which is not in Windows today at all, you’ll have to stick with custom filters – and the risk for doing this. I think a password campaign in your company serves you better than a technical compare to dictionaries. There are enough interfaces out there which you are unable to influence (websites, 3rd-party apps) so your users should get taught what a good password is. Also creating a custom passflt.dll (IMHO) is a technical risk – it could blue-screen your DC since it’s pretty deep in the system. Added features (like dictionaries) might increase the risk of a failure, which might leave your DC in a unstable state.

    To answer your question, if you’d still be able to use a custom filter: as far as I know Yes. However if you want the added features described in this post you might need to get a new version of your filters as well, which take these settings into credit.


  • Nice post Ulf – this comment is similar to what I posted on where this feature is also being discussed right now. The discussions often mention the need of a UI to manage it.

    I don’t think that administrators will need much of a UI to configure password policy – a useful cli-tool should do, as I don’t see this used for too many different policies in a company. There may be exceptions where companies want to configure extra strong policies for (non-admin) users working with more sensitive data, but I don’t expect more than maybe 3-5 policies in most companies (…keep it simple…)

    So while the challenge is not necessarily configuring the policies (even works quite fine with ADSIedit – you only have to get over the time-conversion quirk), it will certainly be understanding the active policy for a specific user, for example when a user calls the helpdesk because he or she has an issue setting a new password… (I can hear them already asking the helpdesk why his 8 char password is not accepted…) How will the helpdesk know which policy applies to the user? What if it’s one that doesn’t have the default domain policy but instead is member of a group that a specific Password Settings Object (PSO) has been applied to?

    This info is easy to retrieve, but it’s not available easily in the current UIs – the following two attributes will retrieve the required data:

    * ms-DS-PSO-Applied => this is a Backlink attribute of a user or group object (corresponds to the ms-DS-PSO-AppliesTo ForwardLink of the respective PSO object) and returns the DN of all the PSOs that are directly linked with the user or group. Note that multiple policies can be applied to a user or group and you’d need to run a query over the various groups and nested groups to determine all the PSOs that are applied directly and indirectly to a user and then evaluate the one with the highest priority/precedence. You’d first want to check If a policy is applied directly to a user as this always takes precedence over any policy applied via a group.

    * ms-DS-Resultant-PSO => this a constructed attribute for users that return the DN of the one resultant password policy that is applied to the user – you do not need to add any additional logic to find the right PSO, as this is what the system has already evaluated in the background.

    Both values only return the DN of the respective PSO => the PW related attributes of the PSO still need to be read and displayed appropriately to be helpful to the admin/helpdesk folks. This is where I expect the need for a UI to be more important – administrators and helpdesk folks will need a simple UI to show the Resultant-PSO and its values of a user. There is not much magic involved in this task, but one that simply needs to get done. It may be best to simply add a small VB script to the ADUC context menus of a user object via display-specifiers to show these values.

    Note that these attributes are not part of any of the existing permission property sets; by default only members of domain admin group have access to the ms-DS-Resultant-POS attribute and PSO objects – as such this is one more thing to consider when delegating rights for other folks to read (or potentially edit) the password policies.

    All in all I believe this is a very powerful feature – even though not all companies will need it. Especially those that try to get rid of the need of user’s typing in their own passwords directly: moving to SmartCards will further increase security and won’t require multiple PW policies…


Leave a Reply