Different Policies, Same Domain

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.

Using ADSI Edit to Create a Password Settings Object

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:

Figure 1

1. Open ADSI Edit from Start > Administrative Tools > ADSI Edit.
2. Right-click ADSI Edit in the left-hand pane of MMC and select Connect to from the menu. Click OK in the Connection Settings dialog.
3. Expand Default naming context under ADSI Edit in the left-hand pane of MMC and find the Password Settings Container under System as shown in Figure 1.
4. Right-click the Password Settings Container and select New > Object from the menu.
5. Click Next on the Create Object dialog (msDS-PasswordSettings is the only possible class).
6. Give the Password Settings Object (PSO) a name, passpol_Accounts, in the Value box and click Next.
7. Password Settings Precedence is used to set a random value, which allows us to control which PSO takes priority should several PSOs apply to one user or group. If we set a value of 20 and later create another PSO that has a Password Settings Precedence value of 30, the passpol_Accounts PSO will take priority if both PSOs are applied to the same user or group object.
8. We don’t want password-reversible encryption, so type False into the Value box and click Next.
9. Configure the PSO to remember 25 of the user’s previous passwords. Click Next.
10. Enable password complexity by typing True into the Value box and click Next.
11. Enter a minimum password length and click Next.
12. Minimum password age must be entered in the following format: D:HH:MM:SS. One day is represented as 1:00:00:00. Click Next.
13. Enter a value of 30 days for maximum password age: 30:00:00:00 and click Next.
14. Set the LockoutThreshold attribute to 5, meaning that after five incorrect passwords, the user’s account will be locked. Click Next.
15. The LockoutObservationWindow attribute corresponds to the Reset account lockout counter after setting in Account Lockout Policy. Enter a value of five minutes (0:00:05:00) and click Next.
16. Finally, set the LockoutDuration attribute, which corresponds to Account Lockout Duration, to a value that is either less than or equal to the LockoutObservationWindow attribute. Click Next and then Finish. The new PSO will now appear in the central pane of MMC.

Apply a PSO Using Active Directory’s Attribute Editor

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:

Figure 2

1. Right-click the passpol_Accounts PSO in ADUC and select Properties from the menu.
2. In the Properties dialog, select the Attribute Editor tab. Click Filter in the bottom right-hand corner and check all the options under Show attributes and Show read-only attributes.
3. In the main Attribute Editor tab window, highlight the msDS-PSOAppliesTo attribute as shown in Figure 2.
4. Click Edit and then Add Windows Account. Select a user from AD and click OK. If you want to apply the PSO to a global security group, you should select Add DN instead and enter the distinguished name of the group. You can add multiple accounts or DNs. Figure 3 shows a user object Accountant1 selected from the Users container. Click OK twice.
   
   

Figure 3

Precedence

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.

Figure 4

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:

1. Select the user or group object, right-click and select Properties from the menu.
2. Go to the Attribute Editor tab and find the msDS-ResultantPSO attribute. If a PSO applies to the object, it will be displayed here as shown in Figure 4. If multiple PSOs are applied to an object, the msDS-ResultantPSO attribute displays the winning PSO.

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.

Figure 5

Shadow Groups

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.