Product Reviews

Pump Up Your Passwords

Specops Password Policy creates and enforces multiple password policies within Active Directory.

• By Danielle Ruest and Nelson Ruest
• 07/01/2006

Gone are the days of simply using your dog's name as a password. The current security landscape demands complex passwords with multiple types of characters, minimum password lengths and many other parameters. You can enforce these types of strong password policies within Active Directory, but there is one significant limitation. You can only enforce one password policy per domain.

Within most AD domain structures, the root domain is the master of the entire forest. Unfortunately, that structure prevents you from enforcing more than one password or account policy. (See sidebar "Domain Design with AD in Mind.")

Using at least two password policies is an effective strategy. For example, one level of password policy would require complex passwords for administrators to access higher-level, domain-wide functions. These passwords would be designed to provide maximum protection. The password rules for regular users would be simpler to enable easier access, but strong enough to provide a decent level of protection.

REDMOND RATING Installation 20% 10 Features 20% 8 Support for Standards 10% 10 Deployment Support 20% 9 Ease of Use 20% 9 Documentation 10% 7 Overall Rating: 8.9 —————————————— Key: 1: Virtually inoperable or nonexistent 5: Average, performs adequately 10: Exceptional

End to Limitations
Specops Password Policy (SPP) can help put an end to AD password limitations, as it lets you maintain and manage multiple password policies within the same domain. You can apply those policies to security groups or organizational units (OU) within your AD domains. This is a major breakthrough on several levels:

• Because you can apply SPP to security groups, you can define a sufficiently complex password policy for high-privilege groups such as enterprise administrators, schema administrators and domain administrators (see "9 Perfect Password Pointers," April 2006). You most likely won't even need a protected root domain, as you can now ensure that your forest-wide roles and privileges are securely protected.
• You can also create a less complex policy for general users by applying it to your user-only OUs. To simplify things, you could also apply it to the Domain Users group (of which every user is automatically a member).
• You can turn OUs into security boundaries of their own. In AD, OUs are technically administrative boundaries only, because they can't adhere to different password policies. With SPP, you can turn OUs into mini-security boundaries by applying special password policies within those units.

There are many possible scenarios for using multiple password policies within the same domain. For example, some organizations create separate domains for developers so they can have looser password policies while actively programming. Using SPP, you wouldn't have to do that because you can place those accounts in special OUs running custom password policies.

This has practical implications beyond mere convenience. Each time you create a domain, you need a minimum of two servers to keep it running--and servers that become domain controllers (DCs) rarely share other roles. Every domain you eliminate saves hardware costs.

[Click on image for larger view.]

Figure 1. Specops Password Policy lets you set a variety of conditions and restrictions for each password rule.

Putting Policy in Place
You'll need both a workstation and a domain controller to deploy SPP, whether those are physical or virtual. SPP includes three components: an administrative console usually deployed on a workstation, a Sentinel service deployed to domain controllers, and a client deployed to each client PC.

You'll only need to deploy the SPP administrative console to administrators. The console needs Microsoft .NET Framework version 2.0 and the Microsoft Management Console version 3.0, so you'll have to make sure those components are installed before installing the console and running the SPP setup. Fortunately, both are present in the SPP setup package.

At the very least, you should deploy the Sentinel service to the PDC Emulator flexible single master of operations (FSMO), but you should really put it on each DC. The client isn't essential, but without it users won't know what rules apply to them.

Once SPP is fully installed and deployed, you can start setting different password policies. SPP will let you apply policies to security groups, OUs and individual users. It's recommended that you only use the former two. Setting password policies at the user level can be cumbersome and problematic.

At the very least, you should set specific password policies to cover enterprise administrators, schema administrators and domain administrators. All of those should have very complex passwords with stringent rules. In the forest root domain, you can assign this to the administrators and the schema administrators groups.

You should also ensure that all Service Accounts have complex, secure passwords. Ideally, these service accounts would be located in a secure OU in the directory. Therefore, the rule should be set against that OU.

User Accounts should have slightly more relaxed rules that still secure the directory, but make it easier for users to get into the system. The easiest way to do this is to modify the default rule (which is applied to the entire domain so it affects all users). You can apply more stringent rules later that will override the default.

Your policies can include rules that exclude words from specific lists, force password expiration at certain intervals, force password reset and generally make password management simpler than if you were using the default Windows capabilities. Each rule provides a series of conditions (see Figure 1), and you can always create more. Rules apply to target users from the moment they are set.

The local client ensures that users know about the rules affecting them as it displays the password policy conditions when they're asked to change their password. You can set rules in priority order. This makes it easy to assign rules that affect all users first, then move down the scale to rules that affect increasingly smaller groups of accounts.

[Click on image for larger view.]

Figure 2. The Specops Password Policy administration interface uses a familiar set of tools.

The Specops Password Policy administration interface is simple and easy to use (see Figure 2). It simply extends the existing Group Policy Object Editor interface, so you can use a familiar tool to modify policies.

SPP can alleviate the need to establish a protected forest root domain by allowing you to highly secure high-privilege accounts in the same domain where users coexist. This means SPP could pay for itself simply by removing the need for the extra domain controllers that are required for the PFRD domain.

Given that, using SPP for greater password flexibility in your AD environment is practically a no-brainer. If you want to enforce better password management in Windows, SpecOps Password Policy will get you there.