Chapter 12. Fine-Grained Password Policies
Undoubtedly, one of the most exciting new features in Windows Server 2008 Active Directory was the introduction of a feature called fine-grained password policies (FGPPs). Prior to FGPPs, domain account policies (password and lockout policies, specifically) could only be set on a per-domain basis. If you had a requirement to have separate password-complexity requirements for different sets of users, you could either deploy a third-party password filter or deploy additional domains. Fine-grained password policies solve both of these issues within a single domain and are immediately available once your domain is running at the Windows Server 2008 or better domain functional level.
12.1. Understanding Password Settings Objects
Fine-grained password policies you create are represented by password settings objects (PSOs) within Active Directory. PSOs are standard Active Directory objects and are stored under the System container in the domain partition.
Fine-grained password policy functionality is available beginning with Windows Server 2008, and as such, Windows Server 2003 and earlier versions of Windows domain controllers are not capable of enforcing this functionality. FGPPs become available once the domain is running at the Windows Server 2008 or better domain functional level. While you can create and manage PSOs before your domain is running at this functional level, the policies will have no effect on users.
The easiest ways to manage PSOs are with the Windows Server 8 Active Directory Administrative Center (ADAC), with Windows PowerShell, or with a command-line tool. We’ll cover management of PSOs with ADAC and a free command-line tool called PSOMgr, available at http://www.joeware.net/freetools/tools/PSOMgr/.
Note
If you’re not familiar with ADAC, take a look at Chapter 3.
12.2. Scenarios for Fine-Grained Password Policies
Nearly all of the settings that you could historically only define in the Default Domain Policy for the entire domain can be configured with password settings objects. The exceptions to this rule are the Kerberos settings that must still be defined on a per-domain basis via Group Policy.
Note
If you are using one or more custom password filters in your domain, you can continue to utilize these filters in addition to fine-grained password policies.
Each of the settings in question is stored as an attribute of the
msds-PasswordSettings schema class that
was added with the Windows Server 2008 schema extensions. These attributes
are outlined in Table 12-1.
Attribute | Description |
| The name of the PSO |
| The order of precedence of the PSO in the event that multiple PSOs apply to a user |
| Toggles storing the password with reversible encryption |
| The number of previous passwords stored in Active Directory |
| Toggles password complexity checking |
| The minimum length of the password |
| The minimum interval before the password can be reset |
| The maximum age of the password before it must be reset |
| The number of failed login attempts necessary to trigger a lockout |
| The number of minutes to lock the account out |
| The time window during which the lockout threshold is maintained |
Defining Password Settings Objects
When you define your strategy for using password settings objects, you will need to determine the number of separate PSOs you will require to implement your strategy, as well as the relevant values for each PSO. All of the settings for a given user will come from a single PSO, as the settings from multiple PSOs are not merged. This may mean that you will need to duplicate some common settings across multiple PSOs.
Generally speaking, you should endeavor to have as few PSOs defined as possible in order to implement your password policies. PSOs add management overhead, and thus each additional PSO will add complexity to your environment. We will discuss the delegation options for PSOs in depth later in this chapter, but keep in mind that, generally speaking, the team that runs the domain will probably be responsible for managing the PSOs; however, the helpdesk staff also need to be aware of them so that they can respond correctly to questions from users, such as “What are the rules for the password that I should enter?” Some organizations may elect to delegate this responsibility to an information security group instead.
Note
As you begin to build your plan for deploying fine-grained password policies, keep in mind that as a general best practice you should aim to limit the number of PSOs in a domain to the minimum number you really need.
Defining PSO precedence
Password settings objects are associated with users either
directly or via group membership. The msDS-PSOAppliesTo attribute of each PSO is a
forward link that can be linked to either users or global groups.
Since the msDS-PSOAppliesTo
attribute is multivalued, a single PSO can be applied to multiple
users or groups simultaneously. The msDS-PSOApplied attribute is a back-linked
attribute of users and groups that defines which PSOs are linked to
it. Since msDS-PSOApplied is a back
link, it is also multivalued, and thus a mechanism must exist to
determine which PSO actually applies to a given user.
Each PSO also has an msDS-PasswordSettingsPrecedence attribute.
This is an integer attribute that must be defined on each PSO and that
controls the precedence of the PSO in the event that multiple PSOs
apply to a given group. Any integer value greater than or equal to
1 and less than or equal to
2,147,483,646 is valid, and it is
recommended that you define a unique precedence value for each PSO in
your domain. The lowest precedence value always wins a
conflict.
Every user object has an additional constructed attribute called
msDS-ResultantPSO. When this
attribute is returned, it will return the PSO that ultimately applies
to the user.
Note
Since msDS-ResultantPSO is
a constructed attribute, you cannot directly query it in an LDAP
filter. If you try to do so, you will receive an error specifying
that you used the wrong matching operator.
Domain Controllers use the following logic to compute the resultant PSO when multiple PSOs apply:
Is a PSO linked directly to the user? This will override any PSOs linked to the user’s groups.
Does a PSO apply to any of the user’s global security group memberships? If so, the PSO with the lowest precedence wins.
Note
If multiple PSOs with the same precedence are found to apply in step 2, the PSO with the mathematically lowest object GUID wins the conflict.
If no PSOs were matched in steps 1 and 2, the Default Domain Policy settings are applied.
12.3. Creating Password Settings Objects
Now that we’ve discussed the basics of password settings objects, we’ll go ahead and provision a PSO in the domain in order to walk through the process.
Password settings objects are stored in the Password Settings container under the System container at the root of your domain, as shown in Figure 12-1. You will need to select View→Advanced Features in Active Directory Users and Computers in order to view the contents of the System container.
PSO Quick Start
One useful feature of PSOMgr is its ability to get you started with a copy of your domain password policy (as defined via Group Policy), as well as some common PSO templates. For the sake of simplicity, we’ll be working with the common PSO templates PSOMgr creates throughout most of this chapter. In order to create these PSOs, you’ll need to run this command: PSOMgr -quickstart -forreal. In any case where PSOMgr is going to make changes to your environment, you must specify the -forreal switch as a confirmation. If you don’t do this, PSOMgr will simply print out the changes it would make if you specified -forreal. Figure 12-1 shows the results of running the -quickstart option.
Building a PSO from Scratch
While the quick-start examples PSOMgr makes are excellent, chances are you may want to define one or more PSOs with custom settings. In this section, we’re going to walk through creating a PSO with the settings defined in Table 12-2 both with the GUI and with PSOMgr.
Setting | Value |
Name | Presidential Policy |
Precedence | 11 |
Reversible Encryption Enabled | No |
Password History Length | 10 passwords |
Password Complexity Enabled | Yes |
Minimum Password Length | 8 characters |
Minimum Password Age | 1 day |
Maximum Password Age | 90 days |
Account Lockout Threshold | 15 failed logons |
Account Lockout Window | 30 minutes |
Account Lockout Observation Window | 30 minutes |
Creating a PSO with the Active Directory Administrative Center
In order to create a PSO with the GUI, we’ll need to use the Active Directory Administrative Center (ADAC). The ability to create PSOs was added to the Windows Server 8 version of ADAC. Previously, to create PSOs with the GUI, you had to use ADSI Edit.
To begin creating the PSO outlined in Table 12-2, launch ADAC and navigate to System→Password Settings Container. Next, right-click and select New→Password Settings. Complete the dialog as shown in Figure 12-2 and then click OK.
Creating a PSO with PSOMgr
Now that we’ve created a PSO with ADAC, we’ll walk through creating the same PSO specified in Table 12-2 with PSOMgr. There are a number of different ways to specify the same data to PSOMgr. Some of them are easier to read than others, so we’ll opt for one of the wordier permutations as opposed to trying to be as succinct as possible.
You can view the full usage screen for PSOMgr by running PSOMgr -help, but the switches we’ll be using and their arguments are:
-add <name>::<precedence>
-lockout <threshold>:<duration>:<observation>
-pwdage <max>:<min>
-pwdlen <minlength>
-pwdhist <historycount>
-pwdcomplex (true|false)
-pwdreverse (true|false)
-forreal
The command to create the PSO from Table 12-2 is:
PSOMgr -add "Presidential Policy"::11 -lockout 15:30:30 -pwdage 90:1 -pwdlen 8 -pwdcomplex true -pwdreverse false -pwdhist 10 -forreal
You should, in turn, receive output similar to the following:
PSOMgr V01.00.00cpp Joe Richards ([email protected]) April 2007 WARN: Using name Presidential Policy for displayName. Using host: ChicagoK8DEVDC01.k8dev01.brianlab.local Retrieving PSOs... Checking existing policies... Creating new PSO: CN=CustomPSO1,CN=Password Settings Container, CN=System,DC=k8dev01,DC=brianlab,DC=local PSO successfully created. Type : Policy Settings Object Domain : k8dev01.brianlab.local Policy Precedence : 11 DN : CN=Presidential Policy,CN=Password Settings Container,CN=System,DC=k8dev01,DC=brianlab,DC=local Name : CustomPSO1 Canonical Name : Display Name : Presidential policy Lockout Threshold : 15 Lockout Duration : 30 Lockout Observation: 30 Min Pwd Age : 1 Max Pwd Age : 90 Min Pwd Length : 8 Pwd History : 10 Pwd Complexity : TRUE Pwd Reversible : FALSE The command completed successfully.
Note
If you use PSOMgr to create a PSO with a precedence value that is already in use, the operation will succeed but will output a warning to the console similar to the following:
WARN: A policy setting object already exists with the same precedence.
WARN: Policy Setting object - DomPol_k8dev01.brianlab.local
WARN: (CN=DomPol_k8dev01.brianlab.local,CN=Password Settings Container,
CN=System,DC=k8dev01,DC=brianlab,DC=local)
WARN: When a single user has two policies assigned with the same
WARN: precedence at the same scope (i.e. directly applied or
WARN: or applied via group), the policy with the lowest GUID will apply.If you want to edit an existing PSO with PSOMgr, you can substitute the -mod switch in lieu of -add. The rest of the switches have the exact same behavior.
12.4. Managing Password Settings Objects
The easiest way to manage PSOs is with ADAC. ADAC exposes all of the options for controlling password and lockout policies as well as for applying PSOs to users and groups. You can also use ADAC to determine what policy applies to a specific user. If you don’t have access to ADAC, or you need to script your management tasks, PSOMgr is an excellent command-line alternative that we’ll also explore.
Strategies for Controlling PSO Application
There are a few strategies for managing which PSO applies to your user population, and you’ll have to decide on which strategy works best based on your organization. The first strategy is to define a global security group for each PSO and apply the PSO to that group. You can, in turn, place users (or nest additional global groups) in the group. The second strategy is to apply PSOs directly to users or existing groups, and the third strategy is to mix application to groups and users where necessary.
Applying PSOs to groups
Applying your PSOs primarily to groups is likely to be the most scalable strategy for many organizations. The strategy here is that you create a global group for each PSO and place the users to whom the PSO will apply in this group. While you can reuse existing global security groups, we recommend that you create new groups dedicated just to application of PSOs. This ensures that you will not affect users inadvertently by adding them to or removing them from a group that controls PSOs or resource access.
It is important to remember that only global security groups are applicable for applying a PSO to a user. While you can link a PSO to a universal or domain local group, it will not actually be considered for application to the user in the resultant PSO calculation.
If multiple PSOs apply to a user by virtue of that user being a member of multiple groups linked to different PSOs, the PSO with the lowest precedence will win, and in the case of multiple PSOs with the same precedence, the PSO with the smallest GUID will win.
Applying PSOs to users
If you have a small organization or intend to manage your PSO application with an automated tool, it may be feasible to apply PSOs directly to users. Note that the application of a PSO to a user is controlled by whoever has access to modify the PSO, not the user. The same precedence rules as with groups apply to user-linked PSOs. However, you should never link PSOs directly to users, even with the availability of the precedence facility.
Mixing group application and user application
Taking a hybrid approach to applying PSOs to users and groups may be the recipe for success in your case. Remember that if a user has PSOs applied to him both by groups and directly to his user object, the PSO applied to the user object will always win. With this in mind, you can define exceptions to the rule where the standard PSO for users is implemented with a group, and exception users are linked directly to an exception PSO.
Managing PSO Application
You can manage PSO application with ADAC, ADSI Edit, Active
Directory Users and Computers (ADUC), or PSOMgr. You control PSO
application by editing the msDS-PSOAppliesTo attribute. We will quickly
go over linking a PSO to a group with each of these tools.
Applying a PSO with ADAC
ADAC lets you apply PSOs from a number of locations, including the properties of users, groups, and the PSO itself. We’ll go ahead and create a global group called “Presidential Policy PSO Group” to which we’ll apply the PSO we created earlier. To apply a PSO to a group, open the properties of the group and then select Password Settings on the left side. Under Directly Associated Password Settings, click Assign and search for Presidential Policy. Once you’re done, the properties of your group should look similar to Figure 12-3.You can also apply a PSO directly to a user using the exact same steps.
To apply settings from the properties of the PSO (or review all of the users and groups the PSO is directly applied to), you can use the Directly Applies To section and add users or global groups to the list.
Applying a PSO with ADSI Edit
Open the PSO you wish to apply in ADSI Edit by browsing to it
under Default Naming Context→DC=domain,DC=com→CN=System→CN=Password
Settings Container, or the similar applicable location in your
environment. If you do not see msDS-PSOAppliesTo in the attribute list,
click Filter and uncheck “Show only attributes that have
values.”
When you edit msDS-PSOAppliesTo, a dialog like the one
shown in Figure 12-4 appears.
This dialog, which was added to ADSI Edit beginning with the Windows
Server 2008/Windows Vista RSAT tools, allows you to either manually
enter a distinguished name (which was the only option in prior
versions) or search for a user or group using the standard Active
Directory object search dialog. Use the Add Windows Account button to
search Active Directory.
Once you click OK and apply your changes, they will take effect immediately (factoring in replication, of course).
You can remove a user or group from the scope of a PSO by using this same process and selecting the user or group and clicking Remove.
Applying a PSO with ADUC
Microsoft added the ADSI Edit attribute editor property page to Active Directory Users and Computers beginning with the Windows Server 2008/Windows Vista RSAT tools. In order to see the attribute editor in ADUC, check View→Advanced Features. Once you browse to System→Password Settings Container under your domain, you will be able to open a PSO and edit it in the exact same manner as in ADSI Edit.
Applying a PSO with PSOMgr
PSOMgr has a versatile syntax for applying and unapplying a PSO.
You can specify a username (sAMAccountName), user principal name (UPN),
or distinguished name (DN) of the object to apply the policy to. As in
the previous examples, we will apply our Presidential Policy PSO to a
group called “Presidential Policy PSO Group.” The switches we will use
to accomplish this are:
-applyto (<samname>|<upn>|<dn>)-pso <psoname>-forreal
For example, psomgr -applyto “Presidential Policy PSO Group” -pso “Presidential Policy” -forreal is the syntax to apply the PSO in this scenario. After running this command, you should get output similar to the following:
PSOMgr V01.00.00cpp Joe Richards ([email protected]) April 2007 Using host: ChicagoK8DEVDC01.k8dev01.brianlab.local Retrieving PSOs... Applying PSO cn=Presidental Policy,cn=password settings container,cn=system, dc=k8dev01,dc=brianlab,dc=local to object CN=Presidential Policy PSI Group,CN=Users,DC=k8dev01,DC=brianlab,DC=local PSO successfully updated. The command completed successfully.
If you want to unapply a PSO, the syntax is nearly identical. Simply substitute -unapplyto for -applyto:
psomgr -unapplyto "Presidential Policy PSO Group" -pso "Presidential Policy"
-forrealViewing the effective PSO
The easiest ways to view the effective PSO for a given user are
with ADAC and PSOMgr. Since the msDS-ResultantPso attribute is computed, it
won’t be displayed in a standard listing of all the attributes of a
user. Active Directory will only return the value of a computed
attribute when it is asked for it explicitly in a search.
Additionally, you cannot construct an LDAP filter that filters on the
value of a constructed attribute, so it is not possible to search
Active Directory for all of the users whose msDS-ResultantPso attribute is a certain PSO.
To display the effective PSO for a given user with ADAC, find the user, and then right-click and select “View resultant password settings.” This will open the PSO that applies to the user and is effective. If a PSO is not applied to a given user, you will receive an error similar to Figure 12-5 that indicates that the password and lockout policy settings in the Default Domain Policy GPO are in effect for that user.
If you don’t have access to ADAC, or need to get the resultant PSOs for a number of users with a script, PSOMgr will be very helpful. Fortunately, there is only one switch necessary for viewing the resultant PSO with PSOMgr:
-effective (samname|upn|dn)For example, psomgr -effective bdesmond is the syntax to view the resultant PSO for user bdesmond. After running this command, you should get output similar to the following:
PSOMgr V01.00.00cpp Joe Richards ([email protected]) April 2007 Using host: ChicagoK8DEVDC01.k8dev01.brianlab.local User: bdesmond | [email protected] | CN=Brian Desmond,CN=Users,DC=k8dev01,DC=brianlab,DC=local Applied PSOs: CN=DomPol_k8dev01.brianlab.local,CN=Password Settings Container,CN=System, DC=k8dev01,DC=brianlab,DC=local Effective PSO: CN=DomPol_k8dev01.brianlab.local,CN=Password Settings Container, CN=System,DC=k8dev01,DC=brianlab,DC=local Type : Policy Settings Object Domain : k8dev01.brianlab.local Policy Precedence : 20 DN : CN=DomPol_k8dev01.brianlab.local,CN=Password Settings Container,CN=System,DC=k8dev01,DC=brianlab,DC=local Name : DomPol_k8dev01.brianlab.local Canonical Name : k8dev01.brianlab.local/System/Password Settings Container/DomPol_k8dev01.brianlab.local Display Name : PSOMGR: Copy of Domain Policy for k8dev01.brianlab.local Lockout Threshold : 0 Lockout Duration : 30 Lockout Observation: 30 Min Pwd Age : 1 Max Pwd Age : 42 Min Pwd Length : 7 Pwd History : 24 Pwd Complexity : TRUE Pwd Reversible : FALSE The command completed successfully.
The first part of the output shows each of the PSOs that apply
to the given user, and the second part shows all of the details of the
PSO that is effective. You can also view the resultant PSO by
accessing the Attribute Editor tab of the properties of a user in
Active Directory Users and Computers. In order to access the Attribute
Editor, you must ensure View→Advanced Features is checked.
Additionally, on the Attribute Editor tab you should check
Filter→Constructed. This will show the msDS-ResultantPSO attribute in the
listing.
12.5. Delegating Management of PSOs
One of the decisions you will likely need to make when planning your implementation of fine-grained password policies is who will manage the PSOs. It is likely that this will fall into the hands of a few different groups or tools, depending on the organization. One possibility is that the Active Directory team will manage the PSOs, in which case this section is somewhat irrelevant. Another possibility is that the PSOs will be controlled by an information security team. A third is that PSOs will be managed indirectly by an identity management/provisioning system.
In the event that the Active Directory team owns PSOs end-to-end, you likely will not need to perform any delegation of security rights to accomplish the management of PSOs. In the event that a separate team such as an information security group controls PSOs, you will need to delegate the necessary rights. In this case, it is likely that there will be three ways you can handle the delegation:
- Delegate access to only application groups
In this scenario you would strictly employ a design of applying password policies based on security groups, with no exceptions. The information security group would be delegated access to these groups and be responsible for managing the membership of the groups. When a new PSO is deemed necessary, this group will need to engage the Active Directory team to create it. This model creates a system of checks and balances to ensure that growth in the number of PSOs is managed. This model would also require that the Active Directory team be engaged to modify the settings on a PSO.
- Delegate access to modify PSOs and application groups
In this case you would delegate access to modify existing PSOs and also to manage the membership of application groups. The information security group would be able to modify the specific settings on a PSO and control where the PSO is applied. If you feel that you will often need to implement exceptions where PSOs are linked directly to users, this model will enable this to be done independent of the Active Directory team. While chances are that changes to PSO settings will be fairly rare, this model also mitigates the need to engage the Active Directory team for those changes. The system of checks and balances for creating new PSOs still exists here.
- Delegate access to create and modify PSOs and application groups
Here we take the previous model one step further and delegate to the information security team the ability to both modify and create new PSOs. If you have a frequent need to create PSOs, this may be the ideal route. Keep in mind that this removes the checks and balances in the other approaches, so there is a potential for the number of PSOs to grow without bound.
If you are going to use your identity management system or
provisioning tool to manage PSOs, you will need to delegate to the account
that tool runs under the necessary rights to manage the PSO application.
This delegation may involve allowing the tool to edit the msDS-PSOAppliesTo attribute directly, and/or
allowing the tool to manage the membership of the application groups for
the PSOs.
Note
For more information about implementing Active Directory permissions and delegations, see Chapter 16.
12.6. Summary
Fine-grained password policies are an important and long-awaited feature. FGPPs allow administrators to define password settings objects and apply different password and account lockout policies to different sets of users in the domain. PSOs can be applied either to global security groups that users are members of, or directly to users.
Managing PSOs is possible with the Active Directory Administrative Center, Windows PowerShell, or the free PSOMgr command-line tool. The PSOMgr tool offers a number of enhanced features that any administrator who is planning to deploy FGPPs should at least investigate.
Due to the manner in which PSOs are implemented in Active Directory, you will need to consider the management and delegation model of those PSOs as it applies to your organization. Applying PSOs to groups provides flexibility in delegating this responsibility.