Security Watch Windows Domain Password Policies

Derek Melber

If you are an administrator of a Windows domain, you are all too aware of the constraints relating to password policies for domain user accounts. With the advent of Windows Server 2008, however, some of those limitations will vanish. Let's take a look at how the new OS resolves one issue: the inability to implement multiple password policies.

If you run any version of Windows® domain today (Windows NT®, Windows 2000 Active Directory®, or Windows Server® 2003 Active Directory), you are limited to a single password policy per domain. In reality, it is not just the password policy that limits you, but rather the broader scope of settings that fall under the Account Policies. Figure 1 shows these policies and settings.

Figure 1 Account policies

These policy settings apply to all domain and user accounts that are associated with the domain, by default. This is because of the way Group Policy inherits down through the Active Directory structure. To get a better feel for how these policies affect domain and local user accounts, it is important to understand where these policies are set and how the inheritance of Group Policy affects all of the different user accounts. (Note that Kerberos policy settings only apply to domain user accounts, as only domain user accounts use Kerberos for authentication. Local user accounts instead use NTLMv2, NTLM, or LM for authentication.)

Setting Account Policies

Within Active Directory, Group Policy establishes and controls the Account Policies for the entire domain. This occurs at the initial installation of your Active Directory domain, and is accomplished by having a default Group Policy Object (GPO) that is linked to the domain node in Active Directory. This GPO, named Default Domain Policy, has default configurations for all three sections of the Account Policies. Figure 2 shows a comprehensive list of the initial settings for the Password Policy items on a Windows Server 2003 domain.

Figure 2 Default password policies for Windows Server 2003 domain (Click the image for a larger view)

The settings in this GPO control the Account Policies for all domain user accounts, as well as for every domain computer. It's important to remember that all domain computers (desktops and servers) have a local Security Accounts Manager (SAM). It is this SAM that is controlled by the settings in this default GPO. Of course, the local SAMs contain local user accounts for the respective computer, too.

The settings in the Default Domain Policy affect all domain computers through the normal inheritance of GPOs down through the Active Directory structure. Since this GPO is linked to the domain node, all computer accounts in the domain will be affected by it.

What You Can't Do with Current Password Policies

A number of misconceptions about password controls surround the current implementation of Active Directory (in Windows Server 2003), despite years of rigorous testing and no evidence that ever proved those misconceptions to be true. It is clear, or should be, that policy will not work in ways other than as designed.

That said, many administrators believe it's possible to have multiple password policies for users in the same domain. They think you can create a GPO and link it to an Organizational Unit (OU). The idea is to move user accounts to the OU so that the GPO will affect the objects. Within the GPO, the Account Policies are modified to create a more secure Password Policy, perhaps by setting the maximum password length to 14 characters. But, for a several reasons, this configuration will never provide the desired outcome. First, the Password Policy settings are computer-based rather than user-based policies. With this foundation for the settings, they will never affect a user account. Second, the only way to modify the Account Policy settings for a domain user account is within a GPO linked to the domain. GPOs linked to the OU that are configured to alter the Account Policies settings will modify the local SAM of computers that reside in the OU, or are in sub-OUs of the linked OU.

A second misconception is that Account Policies settings established in the root domain (the initial domain of the Active Directory forest) will trickle down, or inherit down, through to the child domains in the forest. This, too, is not the case and you can't make the settings function in this manner. GPOs linked to the domain and OUs within one domain will not affect objects in another domain, even if the domain where the GPO is linked is the root domain. The only method for GPO settings to span objects in different domains is to link GPOs to Active Directory sites.

What's in Store for Passwords

As we have just seen, the current versions of Windows handle user account passwords in a simple and straightforward manner. This includes a single set of password rules for all domain accounts, as well as the management of the Account Policies through a Group Policy Object linked to the domain node in Active Directory. All of this goes out the door when it comes to Windows Server 2008.

Windows Server 2008, and the Active Directory infrastructure that comes with it, takes a different approach. Instead of having the Account Policies in a GPO, which allowed only a single policy to be set for all domain user accounts, the settings have now moved into a deeper part of Active Directory. Moreover, Account Policies is no longer based on computer accounts. Now you can target individual users and groups of users to control their password restrictions. This is a radically new concept for Windows administrators, since we have been dealing with Account Policies for computer accounts for so long.

Account Policies within Windows Server 2008

Within Windows Server 2008, you won't be establishing Account Policies with the Default Domain Policy. In fact, you won't be using GPOs for creating Account Policies for domain user accounts at all. In Windows Server 2008, you will be directed into the Active Directory database to make your modifications. Specifically, you will use a tool like ADSIEdit to modify the Active Directory object and its associated attributes.

The reason for this change is that Group Policy isn't designed for multiple passwords within the same domain. The implementation of the multiple passwords per domain capability in Windows Server 2008 is elegant, though not nearly as friendly as everyone would like. Over time, however, the interface for configuring the settings will be easier to access. For now, you need to put on your Active Directory database-hacking hat to get the changes into the system.

You don't have to use ADSIEdit to modify account policy settings if you prefer to do it a different way. You can use any other LDAP editing tool that can tap into the Active Directory database, or even scripting. When implementing your password policies in Windows Server 2008, you will need to take a very different approach than you have in the past. The new capabilities mean you need to consider which users and groups will receive which password settings.

You have to consider not only password length but also the additional restrictions that go along with the Password Policy settings, including minimum and maximum age, history, and so forth. Other concerns include how to control user lockout policy settings and Kerberos settings. There is a one-to-one relationship between the current Account Policy settings and those that are configured in the Active Directory database in Windows Server 2008. However, it's important to note that the names of each policy setting are different now that they are Active Directory objects and attributes.

To implement the new password settings, you must create a Password Settings Object (PSO) named msDS-PasswordSettings under the Password Settings container, which has the LDAP path of "cn=Password Settings,cn=System,dc=domainname,dc=com." Note that domain functional level of the domain you're working in must be set to Windows Server 2008. Under this new object, you will fill out the information for several attributes, as shown in Figure 3.

Figure 3 Password attributes in Active Directory

As you can see, all of the Group Policy settings related to Account Policy settings are duplicated as attributes. Note that there is also a precedence setting; this is essential for implementing multiple passwords in the same domain, as conflicts will surely arise and a mechanism to deal with them needs to be in place.

Targeting Account Policy Settings

For each object you create, you will need to fill out all of the attributes to mold the Account Policy for each user. There is one new attribute, msDS-PSOAppliesTo, that determines which objects will receive the set of policy settings. This is the golden attribute that lets you channel specific settings to certain users. The list under this attribute can either be users or groups but, as with anything else when establishing an access control list, it is best to use groups instead of users. Groups are more stable, more visible, and generally much easier to deal with.

Stand Up and Cheer

For years we've all wanted to be able to use multiple passwords within the same Active Directory domain, and now we can. No longer will every user in the entire domain be held to the same security level when it comes to passwords. Now, for example, you'll be able to have normal users with an 8-character password and IT professionals (who may have Administrator privileges) with a more complex, 14-character password.

It will take some time to get used to going into the Active Directory database to establish or modify the Account Policy settings. Luckily, however, the new settings mimic what you are already familiar with. Be sure to explore these new settings as soon as you get your hands on Windows Server 2008, as they will surely be among the first set of configurations you make.

Derek Melber, MCSE, CISM, MVP, is an independent consultant and trainer. He educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, Security, and desktop management. Derek has authored several IT books, including Microsoft Windows Group Policy Guide (Microsoft Press, 2005). You can reach him at derekm@braincore.net.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.