Documente Academic
Documente Profesional
Documente Cultură
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-ofthe-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
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:
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, lets get going!
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
msDS-PasswordSettingsPrecedence
10
msDSPasswordReversibleEncryptionEnabled
False
msDS-PasswordHistoryLength
32
msDS-PasswordComplexityEnabled
True
msDS-MinimumPasswordLength
16
msDS-MinimumPasswordAge
-864000000000
(9 zeros)
msDS-MaximumPasswordAge
-36288000000000
(9 zeros)
msDS-LockoutTreshold
30
msDS-LockoutObservationWindow
-18000000000
(9zeros)
msDS-LockoutDuration
-18000000000
(9zeros)
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.
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!
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 lets hope so anyway!
Please also read Configuring Granular Password Settings in Windows Server 2008 part 2 when it is
published in short time.
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).
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.
msDS-ResultantPSO
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.
msDS-PasswordSettingsPrecedence
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 msDSPasswordSettingsPrecedence 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!
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.
Scripting
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