Fine Grained Password Policies

New in Windows Server 2008 Active Directory is a feature called fine grained password policies (FGPPs).In Server 2000 and 2003 Active Directory domains, you could apply only one password and account lockout policy to all users in the domain,so if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. In Windows Server 2008 you can use fine grained password policies to specify multiple password policies, apply different password restrictions and account lockout policies to different sets of users within a single domain.FGPPs become available once the domain has been promoted to Windows Server 2008 Domain Functional Level.

To store fine grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services schema Password Settings Container and Password Settings. The Password Settings Container object class is created by default under the System container in the domain. It stores the Password Settings objects (PSOs) for that domain. You cannot rename, move, or delete this container.Policies you create are represented by Password Setting Objects within Active Directory.

Planning for Fine Grained Password Policies

In order to implement fine grained password policies, it is important to be aware of a few things.Fine grained password policies can be applied to user objects, global security groups or inetOrgPerson objects. They cannot be applied to Computer objects,and you cannot apply a fine grained password policy to an organizational unit.

Nearly all of the settings that you could define in the Default Domain Policy for the entire domain can be configured with Password Setting Objects.One exception to the rule are the Kerberos settings that must be defined on a per domain basis via Group Policy.

By default, only members of the Domain Admins group can create PSOs. Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object,and only members of the Domain Admins group have Write permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user. You do not need to have permissions on the user object or group object to be able to apply a PSO to it. To apply a PSO to the user object or group object, you must have Write permissions on the PSO object.

Fine grained password policies do not interfere with custom password filters that you might use in the same domain. If you have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 you can continue to use those password filters. If you want a certain group member to conform to a policy that is different from the policy that is assigned to the entire group, you can assign an exceptional PSO directly to that particular user. If you apply a PSO directly to the user it,takes precedence over all implicit PSOs that might be linked to it when msDS-ResultantPSO for that user is being determined. If there are two or more exceptional PSOs that are applied directly to the user object ( not recommended), the exceptional PSO with the smallest globally unique identifier takes precedence.

Resultant PSO for a User

It is possible for a user or security group to have more than one PSO linked to it. This can happen if a user is a member of multiple security groups, which each have a PSO assigned, or a user object may have multiple PSOs directly assigned to it. In either case, it is important to understand that only one PSO can be applied as the effective password policy.

The following describes how the resultant PSO is determined when multiple PSOs are linked to a user or group:

1. Any PSO directly linked to a user object is the resultant PSO. If multiple PSOs are directly linked to the user object, the one with the lowest msDSPasswordSettingsPrecedence value will be the resultant PSO.

2. If there are no PSOs directly linked to the user, the PSOs for all global security groups that contain the user are compared. The PSO with the lowest msDSPasswordSettingsPrecedence value will be the resultant PSO.

3. If the user does not have any PSOs directly or indirectly linked through group membership, the Default Domain Policy is applied.

Creating a PSO

1.Run the ADSI Edit tool by typing adsiedit.msc.

2. Connect to your domain by right-clicking the ADSI Edit node in the left-hand pane and selecting Connect To. Type in the name of the domain.

3. Expand the domain, expand the DC node, navigate down to CN=System, and select CN=Password Settings Container.

4. Right-click CN=Password Settings Container, select New, and then select Object.

5. Select the msDS-Password Settings object

6. Name the new object.

7. Click Next, and set the precedence value for this object. This value tells you which policy takes precedence if two policies apply to the same user. The lowest precedence wins.

8. Walk through the rest of the wizard and set values for all items.

9. Then you need to configure which users this PSO applies to. To start that process, click More Attributes.

10. From the Select A Property To View drop-down list, select msDS-PSOAppliesTo.

11. Type in the distinguished name (DN) of the user or the global security group you want this policy to apply.

New in Windows Server 2012

In Windows Server 2012, fine grained password policy management is made easier and more visual by providing a user interface for administrators to manage them in ADAC. You can now view a given users resultant policy, view and sort all password policies within a given domain, and manage individual password policies visually. If you plan to use fine-grained password policies in Windows Server 2012, consider the following:

Fine-grained password policies apply only global security groups and user objects (or inetOrgPerson objects if they are used instead of user objects). Default,only members of the Domain Admins group can set fine-grained password policies.You can also delegate the ability to set these policies to other users. The domain functional level must be Windows Server 2008 or higher.

You must use the Windows Server 2012 version of Active Directory Administrative Center to administer fine-grained password policies through a graphical user interface.