Windows Server 2008’s Fine-Grained Password Policies

Executive Summary: Windows Server 2008's Fine-Grained Password Policies let you apply different password policies to various categories of users in your domain.

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.

Using Shadow Groups

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.

Determining which FGPPs are Applied to a User Object

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

The command will return the PSO that applies to the administrator account (if any) in the following format, where passpol_Admins is the name of the effective PSO:

effectivepso
"CN=passpol_Admins,CN=Password Settings Container,CN=System,DC=ad,DC=mycompany,DC=com"
dsget succeeded

If you select Advanced Features from the View menu in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, you can also find the value of the msDS-ResultantPSO attribute by locating the user object with the GUI. Right-click the user, select Properties, and select the Attribute Editor tab. To display the msDS-ResultantPSO attribute, click Filter on the Attribute Editor tab and add Constructed under Show read-only attributes. This method might be easiest for junior Help desk staff.

Using PowerShell to Create PSOs

Microsoft doesn't provide any GUI tools for creating PSOs. If you prefer not to work with standard tools such as ADSI Edit or ldp.exe to add PSOs to AD, Quest Software provides a free set of PowerShell cmdlets as part of the ActiveRoles Management Shell for Active Directory that you can use to administer AD, including some commands for managing PSOs. These commands are also useful for automating the process of PSO creation. Before downloading and installing the cmdlets, you need to install PowerShell and the .NET Framework.

1. Log on as a domain administrator and start PowerShell from the Start menu.
   
2. To work with the new cmdlets from within PowerShell, issue the following command:

   add-pssnapin quest.activeroles.admanagement

3. To create a new PSO for domain administrators, enter

   new-qadpasswordsettingsobject -name admins -precedence 10 -passwordhistorylength 5 -passwordcomplexityenabled $true –minimumpasswordlength 6

4. To apply the policy to the Domain Admins group, enter

   add-qadpasswordsettingsobjectappliesto admins -appliesto 'ad\domain admins'

5. To verify that the admins PSO has been linked to the Domain Admins group and that all the other attributes have been set as required, enter

   get-qadpasswordsettingsobject | format-list

   as Figure 1 shows.
   
   
6. To verify that the Administrator account will inherit the admins PSO, enter

   get-qaduser administrator -includedproperties msds-resultantpso | format-list name, msds-resultantpso

7. Finally, enter the following command to delete the admins PSO:

   remove-qadobject admins

   You'll be prompted for confirmation before the PSO is deleted.

Using Specops to Create PSOs

Another alternative to using ADSI Edit or the command line for creating PSOs is Special Operations Software's Specops Password Policy Basic. You can download this tool for free from www.specopssoft.com/wiki/index.php/SpecopsPasswordPolicyBasic/Download.

Password Policy Basic provides a simple interface for creating, editing, and deleting PSOs. Although only domain administrators can create PSOs, Help desk staff can use the MMC Lookup password policy for user feature to view PSO precedence, as Figure 2 shows.

1. Log on as domain administrator and start Password Policy Basic from the Start menu.
2. Under Connected domains, verify that your domain is listed. In this case the connected domain is ad.com. Click Configure selected domain.
3. The domain's default password policy will appear in the MMC's right-hand pane. Click New password policy to create a new PSO. Name the policy Administrators.
4. Configure the required settings for the PSO under Password policy settings and Account lockout settings, as Figure 3 shows.
5. Click Add member on the bottom right of the Password policy dialog box, add the Domain Admins group in the AD Select Users or Groups dialog box, and click OK.
6. Figure 4 shows the new Administrators policy that now takes precedence for users who are members of the Domain Admins group. If you configure more than one PSO, you can use the arrows on the right-hand side of MMC to change the precedence, with the topmost PSO taking highest precedence.
7. Click Lookup password policy for user and enter the word administrator in the Select Users dialog box. The tool should report that the Administrator account is affected by the Administrators policy.

Until R2...

If you aren't comfortable with Server 2008's built-in AD mechanisms for handling FGPPs, you can use PowerShell or a third-party GUI to configure FGPPs. But take heart: Server 2008 R2 will include PowerShell 2.0, which contains cmdlets for managing FGPPs.