A limitation of previous versions of Windows Server that often made Active Directory (AD) design complex was the inability to assign password policies to different groups of users without creating a separate domain for each group. Consider a situation where the Accounts Department requires a more complex password policy than the rest of the company. The expense of provisioning an additional domain can be prohibitive, especially for small organizations. It may make sense, or even be necessary for compliance or political reasons, to enforce a stronger password or lockout policy for groups of users who have access to sensitive information on the network. Requiring a complex password that has to be changed every two weeks may enrage Mary the receptionist but be a requirement for Bob in Human Resources.
In Windows Server 2008, it’s possible to implement different password and account lockout policies in the same domain by configuring a Fine-Grained Password Policy. FGPPs can be configured only when the forest functional level is set to Windows Server 2008, and created and edited only by members of the Domain Administrators group. The instructions presented here should be carried out on a Windows Server 2008 domain controller (DC) in a test environment.
FGPPs are configured using a new AD object called the Password Settings Object. You can create multiple Password Settings Objects; they are located in the new Password Settings Container. Standard password policies can still be configured using Group Policy as in previous versions of Windows, but Microsoft provides no GUI to configure FGPPs. To do this, you’ll need to use an LDAP tool such as ADSI Edit to modify AD. Log on as a domain administrator and open ADSI Edit:
Now that the PSO has been created, you can open Active Directory Users and Computers (ADUC) from Start > Administrative Tools and access the PSO by switching on Advanced Features in the View menu. If you expand your domain in the left-hand pane of ADUC, and select System and then select Password Settings Container, you should be able to see the PSO in the right-hand pane. Then apply the new PSO to an AD user account:
PSOs that are linked directly to a user object take highest precedence. If there are multiple PSOs linked to an object, then the value of the msDS-PasswordSettingsPrecedence attribute takes effect. Next in line are PSOs linked to groups, and again the msDS-PasswordSettingsPrecedence attribute takes effect when multiple PSOs are linked. Finally, if no PSOs are linked to an object, the password policy defined in Group Policy applies.
How do you know if a PSO has been successfully applied to a user or group? Although it’s not possible to use Resultant Set of Policy (RSoP) in Group Policy Management to check the configuration, there are two PSO attributes that can be used to check the status. Using ADUC with Advanced Features switched on in the View menu:
The msDS-PSOApplied attribute will show the values of all PSOs that apply to the object (Figure 5). You can also use the dsget tool with the new effectivepso switch to display the winning PSO on an object: dsget user <User DN> -effectivepso.
Unless you’re working in a very small organization, I’d recommend creating groups for the purposes of applying PSOs; otherwise, management of granular passwords could become complicated. FGPP supports group nesting, so you can create a global security group for each PSO and nest other groups within it if necessary. Although it is not the best practice to design Organizational Unit (OU) structures according to geographical boundaries, in many organizations this is the case. Microsoft has limited the application of PSOs to global security groups, simplifying management so that users don’t have to be moved between OUs. This would have had many potential implications and in some cases may have required a redesign of an organization’s OU hierarchy to make FGPPs work effectively.
To overcome this restriction, you can automate the creation of a global security group that contains all the user objects within a given OU. This is known as a Shadow Group. The built-in DS commands can be used to easily create and update the membership of a Shadow Group. The following command enumerates all user objects in the Accounts OU and replaces the membership of the AccountsOU_PSO security group with the results:
dsquery user ou=Accounts,dc=ad,dc=com | dsmod group cn=AccountsOU_PSO,cn=Groups,DC=ad,DC=com -chmbr
You could schedule a DS command to automatically add and remove user objects from the AccountsOU_PSO security group, so the group’s membership reflects user objects contained within the Accounts OU.
FGPPs do away with the need for a separate domain if different password policies are required for different sets of users. The initial configuration of FGPPs should be carried out only by experienced administrators who are familiar with editing AD with LDAP tools such as ADSI Edit. Once configured, help-desk staff and junior administrators can manage FGPPs using security groups and standard tools. As with other AD features, FGPPs introduce an additional level of complexity and should be deployed only after careful consideration of implementation issues and potential benefits. If you have a separate domain in your organization for the purposes of implementing password policy, FGPPs could allow you to decommission that domain, reducing complexity and costs.
Russell Smith is an independent consultant based in the United Kingdom who specializes in Microsoft systems management.