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:
Attribute | GPO Branch | Meaning |
msDS-PasswordSettingsPrecendence | 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. |
msDS-PasswordReversibleEncryptionEnabled | 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" |
msDS-PasswordHistoryLength | 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. |
msDS-PasswordComplexityEnabled | 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). |
msDS-MinimumPasswordLength | Password Setting | This attribute defines the minimum lenght of a Password in characters. The domain default would be 7 characters long. |
msDS-MinimumPasswordAge | 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 http://msdn2.microsoft.com/en-us/library/ms974598.... as a guideline.
(domain default: 1 day = -864000000000) |
msDS-MaximumPasswordAge | 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) |
msDS-LockoutThreshold | 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) |
msDS-LockoutObservationWindow | Account Lockout | After which time should the "bad password counter" been reset?
(domain default: 6 min = -18000000000) |
msDS-LockoutDuration | 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!
Appendix:
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