If you would like to read the next article in this series please go to: Configuring Granular Password Settings in Windows Server 2008, Part 2
Introduction
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.
ADUC
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):
Figure 1
GPMC
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’
ADSI Edit
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:
- Create a Password Settings Object (PSO) in the Password Settings Container (PSC) using ADSI Edit
- Configure the PSO options by completing the ‘primitive’ wizard within ADSI Edit
- Assign the PSO to a user account or a global security group
- 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…“
Figure 2
Select OK to choose the default options in the “Connection Settings” dialog:
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…“.
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:
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.
|
Attribute |
Value |
Quick explanation |
|
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 |
What is the minimum password age? (in this case 1 day) NB! Minus sign |
|
msDS-MaximumPasswordAge |
–36288000000000 |
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 |
After how long should the counter for failed attempts be reset? (in this case 6 minutes) NB! Minus sign |
|
msDS-LockoutDuration |
–18000000000 |
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 |
Table 1
When all that typing is done you should see the following dialog – just click Finish.
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:
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:
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.
Figure 9
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.
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)?
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).
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.
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.
Conclusion
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!
Please also read ‘Configuring Granular Password Settings in Windows Server 2008 part 2’ when it is published in short time.
External links
AD DS: Fine-Grained Password Policies
Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration
If you would like to read the next article in this series please go to: Configuring Granular Password Settings in Windows Server 2008, Part 2
