SQL Server Magazine

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

   Prev. page   [1] 2     next page