Beta Man

Password Policy Done Right

Supplement Active Directory's weak password management tools with Specops' Password Policy.

• By Don Jones
• 11/01/2005

Active Directory has been a huge help to administrators, but has always had one significant weakness—password management. You have to manage overall user password complexity levels on a domain-wide basis. While you can change settings in any Group Policy Object (GPO), the prevailing level of password complexity is enforced by domain controllers, and those domain controllers are governed by the same set of Group Policy settings.

It would be helpful to have more granular control over password complexity—to be able to assign and enforce different levels of passwords within the same domain, for example. You could require domain administrator accounts to have long, complex passwords. You could also set temporary or "visitor" accounts to have weaker, although easier to use, passwords.

Specops Software will grant you some of that flexibility with its new Password Policy tool, which complements AD's own password-strength policies. You can assign password policies down to the single user level or across an entire organizational unit. It is fairly intuitive and well thought-out.

Password Policy has two discrete components—an administrative tools component and an enforcement module. The administrative tools extend the Group Policy object editor and the Group Policy Management Console (GPMC) snap-in, if you have it installed. You'll have to install the enforcement module on all domain controllers, as it actually enforces the password policies you'll create.

Specops Password Policy

Version Reviewed: Beta 1 Current Status: Release Candidate Expected Release: 4Q2005—most likely by the time you read this

Installing both of these beta components was fast and error-free. After installing the Password Policy admin tools, you'll open your domain's Default Domain Policy. Under Computer Configuration, browse to Windows Settings and you'll come to the Specops Password Policy section.

Upon initial configuration, the software defaults to a relatively weak six-character password. User names within the password are not allowed. From there, it lets you manage password policy through a fairly robust and attractive-looking user interface (see Figure 1).

Figure 1. The well-designed Password Policy interface gives you easy access to all the password management tools. (Click image to view larger version.)

There's a neat little trick in the interface where you can click on a phrase in the lower-right corner to change the UI's color scheme, cycling through several possibilities. It starts as "Color me green" and changes each time you click it to whatever the next color will be. Apparently the designers couldn't agree what color would be best, so they gave you several options.

Create Those Policies
Now you're ready to start creating password policies, which are simply rule sets. An example of a partial policy is shown in Figure 2. This policy is intended for use with powerful administrator accounts, as it requires long (10-character), complex passwords that include lowercase letters, uppercase letters, a digit and a special character. As before, you can't use a username within a password.

Figure 2. With Specops, you can specify individual password parameters. (Click image to view larger version.)

Any words from a selected word list are also off-limits. The word list feature lets you maintain one or more lists of words that you can't use in passwords—words like Jan, Feb and so forth. These are words that are easy to guess and that users often work into their passwords to make them seem unique. You might also want to prohibit the use of your company name or product names in passwords, since those might also be easy to guess.

One complaint I have about the password policy editing screen is its size. A window of 1024x768 is pretty common on servers, and even more so on clients. If you tend to administer stuff like this through Remote Desktop, though, the screen size tends to be smaller and the dialog boxes don't fit well.

Once you've created your password policy, you can assign members to the policy group. Members can include security groups, organizational units and individual users. The group members are the objects to which the password policy applies. Obviously, it's possible for a member to belong to multiple policies, so you can also define a priority for password policies. If a member has two policies applied to him, the higher- priority one takes effect.

Beta Man's Routine Disclaimer:

The software described here is incomplete and still under development; expect it to change before its final release--and hope it changes for the better.

It's important to note that AD's native password must meet certain complexity requirements so your policy setting isn't overridden by the Specops software. If you leave that setting enabled, users' passwords must meet both the AD and Specops requirements. I suggest disabling the AD policy and using the more flexible Specops system. If you do so, however, define a default password policy in Specops. Otherwise, a user who isn't a member of a Specops policy could end up having a blank password.

It's also critical to install the Specops enforcement module on every domain controller. If users contact a DC where the module isn't running, then the Specops policies won't be enforced. Because Specops policies are stored within AD itself, any changes will take the usual amount of time to replicate to other DCs in your environment.

Enforce Those Passwords
When users change their passwords, the Specops enforcement module goes to work. It reads the Specops policy configuration from AD (note that the Winlogon process does not read these settings, as it does with most Group Policy settings) and determines what password policy to apply to the user based on his identity, group membership, OU membership and the password policy priorities. Then it checks the user's password for compliance with the appropriate policy.

In Beta 1, there's no client piece to the Specops software, so users with improper passwords get the standard Windows error message telling them their password isn't complex enough. Specops tells me they're developing a client component with a more robust password-changing interface, including telling users the precise password requirements. Unless you only have one standard policy for most users and alternate policies for a small group of technically competent users, that client component should reduce help desk calls and ticked-off users.

Wanted: Betas for Review

Beta Man is always on the lookout for quality products to review. If you know of a software product that is currently or soon to be in beta, contact Beta Man at [email protected]. Vendors are welcome, but please act early--the meticulous Beta Man needs plenty of lead time.

One potentially confusing aspect of Specops Password Policy is that it's configured in the Default Domain policy. You'd expect to be able to configure new password policies in any GPO and apply them wherever you want. Keep in mind that password enforcement happens only at the domain controller level, though. That's why Specops' policies are only configured in the Default Domain policy.

Password Policy is easy to install and easy to use. It provides much more granular control and doesn't have a long learning curve (I barely glanced at the dozen-page Word document that came with the beta). I'd like an interface that accommodates a slightly smaller screen, but that's a small nitpick given that most administrators will install the administrative component locally on their client computers and manage domain password policies remotely.

The client component of the Specops Password Policy software wasn't ready in time for Beta 1, and that's an absolutely essential part of making the solution work seamlessly. The ease with which you can deploy and maintain the client could be a major factor in determining whether or not this flexible password management software is the right solution for you.