Windows Server 2008’s Fine-Grained Password Policies

In "Windows Server 2008 Password Policies," Jan De Clercq explains how Windows password policies let you enforce quality requirements for user account passwords and notes that although Windows Server 2003 and Windows 2000 Server password policies let you define only one password policy that applies to all the user accounts in a domain, Windows Server 2008 resolves this limitation. Once you understand how to use Windows password policies in Server 2008, you can deploy fine-grained password policies (FGPPs) to apply different password policies to various categories of users in your domain.

In designing Server 2008's FGPPs, Microsoft moved away from the models used in third-party products and instead created a system in which policies are applied to global security groups rather than organizational units (OUs). When you implement FGPPs in an organization in which Active Directory (AD) has already been deployed, moving users between OUs might negatively affect Group Policy settings or rights delegation, whereas adding user accounts to a new group has no effect on the existing infrastructure.

In Server 2008, security groups can be used to apply FGPPs to an OU. The term Shadow Group simply encompasses security groups that contain all the user objects in a particular OU.

Several tools let you create Shadow Groups, including Windows PowerShell, LDIFDE, and VBScript—but the easiest method is to use AD's built-in directory service commands. The following command runs a query for user objects in the HR OU of a domain called ad.mycompany.com.

dsquery user ou=hr,dc=ad,dc=mycompany,dc=com | dsmod group cn=hr_ou_users,ou=groups,dc=ad,dc=mycompany,dc=com -chmbr

This command also modifies the membership of an existing global security group, hr_ou_users, which is located in an OU called groups, to reflect the results of the initial user query. The dsquery command is used for running LDAP queries against AD. In this example, user specifies the type of object to search for; the results are confined to objects in the HR OU. The dsmod command modifies existing AD objects; group specifies the type of object that will be changed, followed by its exact location in AD. The -chmbr switch replaces all members of the group.

You can then apply a FGPP to the new Shadow Group, and if necessary update the membership of the group by scheduling the command. In effect, this solution applies the FGPP to the user objects located in an OU, even though from a technical perspective the policy is applied to a group.

Only domain administrators can create and modify Password Settings objects (PSOs) and link them to groups under the standard AD security settings. For the purposes of allowing Help desk staff to change the password policy that applies to a particular user, the recommended method is to link PSOs to groups, and let administrators and support staff move users between those groups. If you design an appropriate delegation model for your organization, first-line support staff can change the policy that applies to a user without having to edit AD directly.

When troubleshooting problems related to FGPPs, you might need to determine which PSO is applied to a user account. Doing so isn't always straightforward, because a system of precedence exists when multiple PSOs are applied to groups and/or directly to a user object.

To retrieve the value of the msDS-ResultantPSO attribute for a user account, use the dsget command and specify the distinguished name (DN) of the user object as follows:

dsget user "cn=administrator,cn=users,dc=ad,dc=com" –effectivepso