IntroductionIn 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 classIn 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 needThe
tools and prerequisitesThis is a quick view on the tools and
prerequisites needed for creating additional password
policies.ADUCFirst 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 1GPMCWe 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
EditThe 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 stepsThis 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 appliedNow that we know what
steps we have to take, lets get going!Lets get startedFirst, 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 2Select OK to choose the default options in the
Connection Settings dialog:
Figure 3In 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 4You 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 5From 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.AttributeValueQuick explanation
CnPassPolAdminsThis 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-PasswordSettingsPrecedence10This 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-PasswordReversibleEncryptionEnabledFalseBoolean value to
select if passwords should be stored with reversible encryption
(usually not a good idea).
msDS-PasswordHistoryLength32How many previously used passwords
should the system remember?
msDS-PasswordComplexityEnabledTrueShould the users use a complex
password? (Boolean value)
msDS-MinimumPasswordLength16What 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-LockoutTreshold30How 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
Table 1When all that typing is done you should see the following
dialog just click Finish.
Figure 6Make it happenNow 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 7From 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 8If 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 9In 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 10In 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 11This 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 12This 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 13NB! 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.
ConclusionWe 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).Who can hit what?At the riskof repeating
myself I must say this to make sure it is 100% clear. The new
multiple password policy functionality in Windows Server 2008
(Codename Longhorn) allows us to set individual password policies
and account lockout policies on user objects, interOrgPerson
objects and global security groups.Fine-grained password policies
cannot be applied to an OU directly now we must apply these
policies to groups instead. Not any kind of group it must be
security groups set to the global scope. Its possible to set the
options/attributes on other groups; however it will not work as
expected (the settings are ignored).If we really want to handle
password policies within the OU structure, theShadow Groups can be
useful see the section Shadow Groups and how to script them later
in this article.By default only members of the Domain Admins group
can set, create and delete fine-grained password policies better
known as Password Setting Objects (PSO). However, these permissions
can be delegated and tweaked if required, but the default settings
should be fine for most environments. To be more specific, only
members of the Domain Admins group have the required Create Child
and Delete Child permissions on the Password Settings Container
(PSC) object. To apply a PSO to a user or a group object, you must
have Write permissions on the PSO object members of the Domain
Admins group are the only ones with this permission by default. The
funny thing is that you dont have to have permissions on the user
or group object itself, as these are set by a background directory
process.Take a look at those attributesI just have to mention some
of the attributes that make all of this possible.msDS-PSOAppliesTo
Every PSO has a multi-valued attribute named msDS-PSOAppliesTo
which is known as a forward link, linking to user or group objects.
It can link to a single user, a single group, multiple users,
multiple groups or multiple users and groups. These links are
actually just the distinguished names (Eg.
CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local) of the associated
objects. You might ask: What if we rename or move a user or group
object (to another OU or container), will the PSOs follow the
objects? Yes - the PSOs msDS-PSOAppliesTo attribute is
automatically updated by the directory service in the background,
to point to the new location (distinguished name) of the changed
object.msDS-PSOAppliedThe just mentioned msDS-PSOAppliesTo
attribute on the PSOs can be edited as opposed to the back link
attribute msDS-PSOApplied which is present on user and group
objects. The latter attribute is view only and handled by the
directory service in the background.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-ResultantPSOThe
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-PasswordSettingsPrecedenceThe
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 designBefore 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 rulesThe 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 userare 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
msDS-PasswordSettingsPrecedence 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!As more general recommendations I will
mention these:The Description field can be used to specify the
password and lockout settings that are enabled in the PSO. Use it
for a quick wrap-up of the PSO configuration and intended
use.Create a naming convention for PSOs like you have for other AD
objects etc.Assign PSOs to groups, instead of directly on user
objects, for better overview and easier manageability.Assign a
unique precedence value to each of the PSOs in your domain, it will
then be much easier to determine the effective password policy for
a certain user object.The Default Deny All ruleWell, I know this
might not be a popular thing to say, but I would recommend you set
the password settings contained in the Default Domain Policy to a
very high (almost annoying) level of security. This is because you
or somebody else might forget to include a user in one of the
password security groups. In that case the user accounts password
policy will fallback to the one defined in this default policy set
on the domain level.Look at the security policy in the Default
Domain Policy as the Default Deny All rule in a firewall if no
specific rule/policy is available for the user (or one of the
groups of which he is a member) then we should place a very strict
policy on the users head. The user will probably call help desk to
get this fixed ASAP - if we give the user a very relaxed password
policy instead he/she will, in most cases, never complain.Another
way to do this would be to set a granular password policy on the
Domain Users group with the lowest priority used - but again, at
some point an account might slip out of this group for some reason
My choice is definitely the Default Deny All rule as always!Shadow
groups and how to script themIf you have never heard about Shadow
Groups, do not worry neither had Itwo months ago. A Shadow Group
(SG) is a security group (in this case a Global security group)
that contains the objects within a given OU as members. A SG is a
security group that is logically mapped to an OU you could say.For
instance you might have an OU,
OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local, with the user accounts
for the entire sales department a SG would be a group that matched
that content 100%. For password policies this can be a really good
thing if we want the password policies to follow the OU structure
virtually, instead of following the Security Group structure.You
can probably imagine that this would mean a great deal of work if
we had to update the SGs manually every hour or so that is why I
have written a small and simple VBS script to automate this process
by using a scheduled task.The script collects the user accounts
from a specific OU - specified as an argument to the script and
places those into a dictionary object. The script then collects the
users within a specific group - specified as an argument to the
script - and places those into another dictionary object. By
comparing those dictionaries, the script adds or removes users from
the shadows group. The script is designed to be scheduled as a task
and should be used with the following syntax: ShadowGroup.vbs
"Target OU" "Shadow Group"Example:ShadowGroup.vbs
"OU=Test,DC=Contoso,DC=Local"
"CN=Shadow,OU=Test,DC=Contoso,DC=Local"The script can be downloaded
here, but use in a production environment is at your own risk. It
is recommended to put in some error handling routines and maybe
reporting functionality. Also support for 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.ScriptingIt 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
ReadyI 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