Executive Summary: Microsoft’s Windows password policies let you enforce password quality requirements for the passwords of user accounts. Windows Server 2003 and Windows 2000 Server password policies let administrators define only one password policy that applies to all user accounts in a domain. Windows Server 2008, Microsoft’s upcoming Server OS, resolves this limitation.

One of Windows’ most important security policies that every Windows administrator is certainly familiar with is the password policies. These policies let you enforce password quality requirements (e.g., minimum password length, maximum password age) for the passwords of local or domain user accounts. As you might know, Windows Server 2003 and Windows 2000 Server password policies have some important limitations. In this article I explain these limitations and discuss how Windows Server 2008—Microsoft’s upcoming Server OS—resolves them. I also explain how you can configure and use Server 2008’s password policies. At press time, Microsoft had released Server 2008 Release Candidate 0 (RC0) and was planning to launch the Server OS on February 27, 2008.

A Flexible Solution for a Serious Problem
A serious limitation of the password policies in Windows 2003 and Win2K is that administrators can define only one password policy that applies to all user accounts in a domain. You can define this global domain password policy from the Default Domain Policy Group Policy Object’s (GPO’s) Password Policy settings or from any other GPO that’s linked to the Active Directory (AD) domain object. To access the Password Policy configuration interface, go to the \Computer Configuration\Windows Settings\Security Settings\Account Policies GPO container. Even though you can define different password policies in the GPOs and link them to AD organizational units (OUs) or computer accounts, these password policies don’t apply to domain accounts—instead, they apply to the local accounts that are defined in the security databases of the computer accounts to which the GPOs apply.

Organizations typically want to impose different password quality requirements for certain categories of domain accounts. A classic example is having a different password policy for administrator accounts and regular user accounts. The security rationale is simple: Administrator accounts have more powers (permissions and rights) than plain user accounts, so you might want a higher quality authentication process for administrators than for regular users. Another way to provide stronger authentication is to enforce the use of smart card logon for administrator accounts.

Windows 2003 and Win2K provide two workarounds for organizations that want to define different passwords policies in a single domain, although both workarounds are difficult to implement. One workaround is to deploy separate domains for each of the account categories that you want to define a special password for. The other workaround is to develop a special “password filtering” DLL that you then deploy to all your domain controllers (DCs). The second solution is rarely used because it’s even more complex and time consuming than the first solution.

Server 2008 comes to the rescue by introducing fine-grained password policies that let administrators define different password policies for different domain account categories in a single domain. This new fine-grained password policy functionality can be applied only to domain accounts—not to local accounts.

Server 2008 introduces the same functionality for the account lockout policies that in earlier Windows Server versions were crippled by the same limitation (i.e., you could define only a single account lockout policy for all domain accounts). Account lockout policies ensure that user accounts automatically become unusable after a user enters a certain number of incorrect passwords. The administrator must define a bad password threshold to configure the account lockout policy.

Configuring Fine-Grained Password Policies
Configuring Server 2008’s fine-grained password policies is entirely different from defining the classic domain account or local account password policy in earlier Windows versions (which I described previously). You can’t use GPO settings to configure fine-grained password policies, because Microsoft uses a different (non–GPO-based) mechanism to store and enforce these policies.

Server 2008’s fine-grained password policies are stored in a new AD container called the AD Password Settings Container, which is located in the System container of the AD domain naming context. To define a new fine-grained password policy, you must create a new AD object of the msDS-PasswordSettings object class in this container. Objects of this class are referred to as Password Settings objects (PSOs) in the Microsoft documentation. By default, only members of the Domain Admins group can create PSOs, because only members of this group have the AD Create Child and Delete Child permissions on the Password Settings Container. (I discuss the tools you can use to create and configure PSOs in a later section.)

To apply the PSOs you created, you must link the PSO to an AD user or group object. To do so, you don’t need permissions to the AD object itself; you simply need Write permissions on the PSO. By default, only members of the Domain Admins group have this permission. Therefore, only members of the Domain Admins group can link a PSO to a group or user—although you can obviously delegate these permissions to other administrators.

Table 1 summarizes the attributes that are linked to Server 2008 PSOs. Note that a PSO can store not only password policy settings but also account lockout policy settings. Remember that Server 2008 supports both fine-grained password and account lockout policies. Two important PSO attributes are the msDS-PSOAppliesTo and msDS-PasswordSettingsPrecedence attributes.

The msDS-PSOAppliesTo PSO attribute is a multi-valued attribute that determines what AD user accounts or groups the PSO will be linked to. Even though password and account lockout policies can be linked to any AD user, group or computer object, or OU, PSOs are effective only for the user accounts and global groups they are linked to. In addition, PSOs are effective only if your AD domain is in the native Server 2008 domain functional level—which means that all the DCs in your domain must be running Server 2008.

The msDS-PasswordSettingsPrecedence PSO attribute holds an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object. A low value for the msDS-PasswordSettings Precedence attribute indicates that the PSO has a higher priority than other PSOs. For example, imagine that a user object has two PSOs linked to it: one PSO that has an msDS-PasswordSettings Precedence value of 10 and another PSO that has a value of 40. In this case, the PSO that has the msDS-PasswordSettingsPrecedence value of 10 (the lower value) has a higher rank and will be applied to the user object. If multiple PSOs are linked to a user or group, the logic that Server 2008 uses to determine the resultant PSO is as follows:

• A PSO that is linked directly to the user object is the resultant PSO. If more than one PSO is linked directly to the user object, the PSO with the lowest msDS-Password- SettingsPrecedence value is the resultant PSO.
• If no PSO is linked to the user object, but PSOs are linked to global groups the user is a member of, Server 2008 compares the msDS-PasswordSettingsPrecedence values of these different global group PSOs. Again, the PSO with the lowest msDS-Password- SettingsPrecedence value is the resultant PSO.
• If no PSO is obtained from these conditions, the “classic” Default Domain Policy is applied.

To let administrators easily determine the PSO that’s ultimately applied to a user, Microsoft added a new attribute called msDS-ResultantPSO to each AD user object. This attribute holds the distinguished name (DN) of the PSO that’s applied to a given user.

Continue to next page

PSO Creation and Configuration Tools
Microsoft doesn’t plan to provide a GUI tool or Microsoft Management Console (MMC) snapin extension to configure fine-grained password policies in the first Server 2008 release. However, you can use existing LDAP query tools such as LDP or LDIFDE, or the MMC ADSI Edit snap-in, to define and configure PSOs. These tools are available on any Server 2008 AD installation. Although these three tools are rather complex, experienced AD administrators should have no problem using them to set the new password policies.

Novice AD administrators, or experienced administrators who simply want to make their jobs easier, might consider Joe Richards’ command- line tool called psomgr.exe, or Special Operations Software’s Specops Password Policy tool. Specops Password Policy lets you use a special MMC snap-in to configure PSOs from the Windows GUI. Both tools hide the AD complexity behind fine-grained password policies and significantly ease their configuration. You can download the PSOMgr tool from www.joeware.net/freetools/tools/psomgr. The fullfeatured commercial version of Specops Password Policy is available at www.specopssoft.com/products/specopspasswordpolicy; a free version with limited functionality, called Specops Password Policy Basic, is available at www.specopssoft.com/wiki/index.php/specopspasswordpolicybasic. The full-featured version extends the standard Windows password policy capabilities by adding features such as the ability to disallow the use of user names or certain words in passwords, and automatic user notification of password expiry via email message.

To use ADSI Edit to define a new PSO, start ADSI Edit and connect to the domain where youwant to define a fine-grained password policy. Then, navigate to the System\Password Policy Settings container. Right-click the container and select New, Object. In the Create Object dialog box, which Figure 1 shows, select the msDSPasswordSettings object class, and enter your preferred password and account lockout policy values for the different PSO attributes.

To use LDP to define a new PSO, you must initiate several LDAP commands from the LDP interface. (For information about using LDP, see the Microsoft article “Using Ldp.exe to Find Data in the Active Directory,” at support.microsoft.com/kb/224543.) To use the LDIFDE command line to define a new PSO, you must first create an LDF configuration file that specifies the different PSO attributes. (For information about using LDIFDE, see the Microsoft article “Using LDIFDE to import and export directory objects to Active Directory,” at support.microsoft.com/kb/237677. For more detailed instructions, see the Microsoft article “Stepby- Step Guide for Fine-Grained Password and Account Lockout Policy Configuration,” at technet2.microsoft.com/windowsserver2008/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true.)

When you use the ADSI Edit version that’s bundled with Server 2008 to define PSOs, you must enter the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) in the days:hours:minutes:seconds format. For example, to set a maximum password age of 40 days, you’d enter the value 40:00:00:00. When you use the ldifde command or an older (pre-Server 2008) version of ADSI Edit to create PSOs, you must enter the values of these attributes in I8 format (i.e., integer represented in 8 bytes). In the I8 format, time must be stored in intervals of -100 nanoseconds. This means that to use LDIFDE or an older ADSI Edit version to set PSO attributes to their appropriate values, you must convert the time you want to set in values in minutes, hours, or days to time values in intervals of 100 nanoseconds, then precede the resultant values with a minus sign (-).

Because the I8 format is difficult to use, I recommend that you use the Server 2008 version of the ADSI Edit tool (or the PSOMgr or Specops Password Policy tools) for defining PSOs. The Microsoft article “Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration” (technet2.microsoft.com/windowsserver2008/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true) explains I8 conversion in more detail.

In addition to using ADSI Edit, LDP, LDIFDE, PSOMgr, or Specops Password Policy to link PSOs to users or global groups, you can also use the MMC Active Directory Users and Computers snap-in. To link a PSO to a user or group from this snap-in, open the snapin and ensure that the Advanced Features view is enabled. (To enable this view, use the Advanced Features option in the View menu.) Then, open the Passwords Settings Container in the System container, right-click the PSO you want to link, and select Properties. In the Properties dialog box, select the Attribute Editor tab, select the msDS-PSOAppliesTo attribute, and click Edit. Finally, in the Edit dialog box, which Figure 2 shows, enter the DN of the user or group you want to link the PSO to. If you don’t know the correct DN of a user or group, you can obtain it from the Active Directory Users and Computers snap-in. In the snap-in’s details pane, right-click the user or the global security group, select Properties, select the Attribute Editor tab, and view the value of the user’s or group’s distinguishedName attribute in the Attributes list.

A Valuable Addition
Server 2008’s fine-grained password and account lockout policies are a valuable addition to the Windows security management portfolio. Although defining and configuring these policies isn’t straightforward in the first Server 2008 release (I strongly advise you to use PSOMgr or the Specops Password Policy tool), the policies do provide a significant level of additional flexibility. For example, Server 2008’s fine-grained password policies eliminate the need for organizations to define additional Windows domains or develop special password filters.