Windows Insider

The Password Drama Continues

Setting password policies is tricky enough. Now, throw Windows Server 2008 into the mix.

• By Greg Shields
• 12/01/2007

The reason for this limitation is because password policies, unlike all other Group Policies, are traditionally applied only at the domain level. More domains mean more domain controllers (DCs), and that means more management headaches. So our solution to the problem sometimes means changing everyone's policy to something less secure.

In the Windows Server 2008 episode of this soap opera, the storyline changes a little. Server 2008 adds the concept of "fine-grained password policies." Configuring policies like these means you can now create different password policies for different groups of people. If your executives want a year, give it to them. For your semi-trusted external contractors with domain accounts, make them change it every 30 days.

By upgrading your domain controllers and your Domain Functional Level to Server 2008, you gain the ability to create and apply Password Settings Objects (PSOs) to domain users and groups. However, there's one interesting nuance.

Simplifying Complexity
Although much of Server 2008's new functionality is intended to simplify common administrative tasks, the process of creating PSOs and assigning them to users and groups is terribly complex. It involves manually creating Active Directory objects within its database. So let's try here to take some of the complexity out of the process.

Here's what you'll need to do. First, ensure that your domain is at the Windows Server 2008 Functional Level. This will require a schema update to bring new Server 2008 DCs online, and it will also mean you'll need to upgrade all DCs in your domain to Server 2008.

Once this is complete, launch the adsiedit tool and connect to the Default Naming Context. There, under the {Domain} \ CN=System \ CN = Password Settings container, right-click to create a New Object. You'll be creating an object class of msDS-PasswordSettings. This is the aforementioned PSO.

Once created, we'll populate the characteristics of this PSO with the settings we want for our users for things like password length and maximum age. Here's an explanation of those attributes:

• Cn: This is the friendly name for the PSO you're creating.
• msDS-PasswordSettingsPrecedence: This is the PSO's priority. We'll talk about priority below.
• msDS-PasswordReversibleEncryptionEnabled: This is a True/False value for Reversible Encryption.
• msDS-PasswordHistoryLength: This is an integer value for the number of passwords you want the system to remember.
• msDS-PasswordComplexityEnabled: This is a True/False value for Password Complexity.
• msDS-MinimumPasswordLength: This is an integer value for the minimum password length.
• msDS-MinimumPasswordAge: This is an integer value preceded by a minus sign for the minimum password age.
• msDS-MaximumPasswordAge: This is an integer value preceded by a minus sign for the maximum password age.
• msDS-LockoutThreshold: This is an integer value for the number of bad passwords allowed before the account locks.
• msDS-LockoutObservationWindow: This is an integer value preceded by a minus sign for the amount of time given to the lockout counter.
• msDS-LockoutDuration: This is an integer value preceded by a minus sign for the amount of time an account is locked out.

Where this gets particularly complex is with the four time-based elements previously listed. The values used here are based on a programmatic formula that's fairly complex to calculate without a tool to assist you. You can't just enter a number of milliseconds or other time value into this entry to get the correct result. As an example, the value for one day is -864000000000.

For links to online resources that will help you calculate the correct values, see the "More Information" box at the end of this column.

Once you've created the policy, you can then right-click that policy in adsiedit and choose properties to apply it to a user or Global Group. Do this in the Attribute Editor by editing the msDS-PSOAppliesTo attribute and entering in the full distinguished name (DN) of the user or group.

For example, for the Executives global group in the People organizational unit (OU) for the abccorp.com domain, the DN would be CN=Executives,CN=People,DC=abccorp,DC=com. It's important to note here that you can't apply policies to OUs, only users and groups.

Only one PSO can apply to a particular user at a time, so there are some rules that determine their application should multiple PSOs be applied to the same user. PSO's applied directly to a username take precedence over those applied to them via a group membership. Earlier we talked about the priority attribute msDS-PasswordSettingsPrecedence. If multiple policies apply to a user via multiple group memberships, then the policy with the lowest precedence number will apply.

When all else fails and two PSOs have the same precedence, the one with the lowest globally unique identifier (GUID) is applied. As GUIDs are more or less randomly generated this can cause some unpredictable results. The moral here is to always give your PSOs unique precedence values to prevent that last rule from applying.

As you can see, Server 2008's episode of this ongoing saga does provide some new benefits. Like all soap operas, there's always a little drama before the plot goes anywhere. In our case, the complicated procedure with PSOs is the drama you'll need to endure to finish the saga.

[The information in this column is based on the beta 3 version of Windows Server 2008. The process may change prior to the full release of Server 2008. -Ed.]