Specops Password Policy
If you need multiple password policies, make your life easier and check out Specops Password Policy.
February 26, 2008
I like to keep my networks as simple as possible. Unless there’s a business reason to do otherwise, I recommend that Active Directory (AD) forests be kept simple and have just one domain. Many of the reasons for why we used to create multiple NT 4.0 domains can be eliminated with a good organizational unit (OU) structure, delegated permissions, and Active Directory Sites. The only remaining reason to use multiple domains in a forest is if business units need a separate password policy, because the password policy settings are kept in the default domain Group Policy Object (GPO) at the root of the domain. Although each new GPO has the settings for a password policy, the only settings that are applied are the ones at the root level.
In my quest to keep the AD forest as simple as possible, and yet be able to set multiple password policies, I tested a tool from Special Operations Software. Specops Password Policy (SPP) is a password policy enforcer that lets you create multiple password policies in the same domain.
Installing SPP
As in most of my reviews, I used VMware Server 1.04 to simulate a standard network. The domain controller (DC) for the specops.local domain ran on a virtual machine (VM) with Windows Server 2003 SP2 and all the latest security patches.
I initially was frustrated with what seemed to be a lack of documentation for the Specops application. However, I then found a well-organized set of Wiki articles at the Specops Web site at www.specopssoft.com/wiki. These documents provided everything that I needed to know to set up the product and apply my first password policy. Each article is available for download as a PDF if you need to read it offline. If you have a question that the Wiki can’t answer, check out the Specops-sponsored forum at www.specopssoft.com/forum. Other vendors should take note: This is how online documentation should be set up.
After I installed Microsoft .Net Framework 2.0 SP1 and the Group Policy Management Console (GPMC) on the DC (both are prerequisites for installing the Specops application), I was ready to install the Specops Password Policy Domain Administration tool by clicking Setup.exe. The software installation requires a reboot, so be sure to add this to your deployment plan. You must complete three tasks to install the product:
Install the Administrative tools locally and add the license
Deploy the Specops Password Policy Sentinel service to the DCs
Deploy the Specops Password Policy Client to the client computers
Each step has a separate tab in the set-up routine that steps you through the process. If the machine doesn't have the correct prerequisites, then detailed instructions with graphics are provided to guide you through.
The easiest way to ensure that all of your DCs are running the required software is to add a GPO to the DC OU that deploys the SpecopsPasswordPolicySentinel-x86.msi or SpecopsPasswordPolicySentinel-x64.msi (for 64-bit DCs). You can also use a GPO to ensure that SpecopsPasswordPolicyClient-x86.msi is installed on each client in your domain.
After the installation was finished, I registered a special Specops extension to the Active Directory Users and Computers extension by running SpecopsAducMenuExtensionInstaller.exe with the parameter /add, which let me see the new Specops features in Active Directory Users and Computers, which Web Figure 1 shows. What's nice about this added functionality is that it’s not a Schema update but simply updates the Active Directory Users and Computers tool.
Deploying a Password Policy
Now I was ready to create my first password policy. Remember, only one password policy can be enforced with an NT 4.0 domain or Windows 2003/2000 AD. However, Specops allows multiple policies in the same domain by applying the policy to organization units via a Group Policy Object. If your OU structure is logically ordered, then you'll be creating policies in no time. If not, you'll need to organize your OU a bit to make it easier to deploy the policies. I organized my AD domain as AllUsers, IT, Management, Sales, and Temp.
I decided to create a separate password policy for each OU under AllUsers. I followed the Getting Started Wiki that I found online, and it stepped me through creating all of the policies. SPP is laid out extremely well and is very simple to navigate. You use this one tool to create password policy templates. You then use the standard Microsoft Group Policy Management Console (GPMC) to deploy the templates via Group Policy, which Web Figure 2 shows. It couldn't be simpler.
When I was done, the IT OU had a very strong password policy, and the Management OU had an extremely simple policy where they never have to change their password (I grow tired of always having to reset their passwords because they keep forgetting them). The Sales policy was standard, but I required them to change it every 30 days instead of every 90—these road warriors use public PCs and wireless networks in airports and hotels, and I want them to always have a fresh password.
With SPP, an endless set of password policy configurations is available. Some configurations will be familiar as they mimic the standard settings in the default domain GPO. Other settings will be a new and welcomed sight. For example, not only can you require the setting “three of the four” character types as the standard Microsoft “complex password setting” requires, you can specify how many of each character is required—you could, say, require that a password contain two uppercase letters, three lowercase letters, four numbers, and one special character.
Another useful feature is the “Disallow incremental passwords” setting. How many users do you know who simply add a 1 or a 2 at the end of their password when they’re prompted to change it? The disallow setting prevents users from creating potentially repetitive and weak passwords. Some other settings that I thought were interesting included the following:
Disallow a digit as the first character
Disallow consecutive identical characters
Disallow words from a custom dictionary
Send email password expiration notification
You’ll find additional settings to help you build the perfect password policy. If you can imagine it, there’s probably a setting for it.
Keep It Simple
I still believe that unless you have a really good reason to add multiple domains to a forest, you should try to keep AD as simple as possible. However, if you’re contemplating adding a second domain because you have to have another password policy, then I recommend that you make your life easier and check out Specops Password Policy.
About the Author
You May Also Like