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…”
Select OK to choose the default options in the “Connection Settings” dialog:
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…”.
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:
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.
|Cn||PassPolAdmins||This is the name of the policy. Try to come up with a naming convention for these policies if you will have lots of them.|
|msDS-PasswordSettingsPrecedence||10||This number is used as a ‘cost’ for priority between different policies in case a user is hit by multiple PSOs. Be sure to leave space below and above for future use. The stronger the PSO password settings are, the lower the ‘cost’ should be.|
|msDS-PasswordReversibleEncryptionEnabled||False||Boolean value to select if passwords should be stored with reversible encryption (usually not a good idea).|
|msDS-PasswordHistoryLength||32||How many previously used passwords should the system remember?|
|msDS-PasswordComplexityEnabled||True||Should the users use a complex password? (Boolean value)|
|msDS-MinimumPasswordLength||16||What should be the minimum number of characters in the user accounts password?|
|msDS-MinimumPasswordAge||–864000000000 (9 zeros)||What is the minimum password age? (in this case 1 day) NB! Minus sign|
|msDS-MaximumPasswordAge||–36288000000000 (9 zeros)||What is the maximum password age? (in this case 42 days) NB! Minus sign|
|msDS-LockoutTreshold||30||How many failed attempts before the user account will be locked?|
|msDS-LockoutObservationWindow||–18000000000 (9zeros)||After how long should the counter for failed attempts be reset? (in this case 6 minutes) NB! Minus sign|
|msDS-LockoutDuration||–18000000000 (9zeros)||For how long should the user account object be locked in case of too many bad passwords entered? (in this case 6 minutes) NB! Minus sign|
When all that typing is done you should see the following dialog – just click Finish.
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:
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:
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.
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.
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)?
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).
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.
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.