In-Depth

How To Manage Active Directory Password Policies in Windows Server 2008/R2

So, you think you know how password policies work in Active Directory? Well, you might ... or you might not. Find out how to manage Active Directory password policies in Windows Server 2008 and Windows Server 2008 R2.

• By Derek Melber
• 08/03/2011

Some things in life, like death and taxes, are guaranteed. There are other things in life that you think are guaranteed, or at least you think you know how they work -- such as Active Directory password policies. Then, there are things that you want to work, and when they come along, you feel you know how they work before you even look at them -- such as fine-grained password policies (FGPPs). I'm not going to discuss death and taxes, but I am going to clarify the misconceptions surrounding Active Directory password policies and FGPPs.

With the technology of password policies having existed for more than 10 years now, you'd think this topic would be infinitely clear. However, based on my exposure to network administrators who are still confused about how Active Directory password policies work, that's not the case.

Basic Facts
These basic facts have been the same in Active Directory domains since Windows 2000, which was released 11 years ago:

• The Default Domain Policy defines the password policies by default for every user in Active Directory and every user located in the local Security Account Manager (SAM) on every server and desktop that joins Active Directory.
• There can be only one password policy for domain users in a Windows 2000 and Windows Server 2003 Active Directory domain.
• It's not possible to configure the password policy for an organizational unit (OU) of users to be different than that of other users in the domain or in a different OU.
• The password policy settings can't be extended to include additional settings without using a third-party tool or developing a custom password policy solution.
• It's not possible to configure a password policy for the root domain and have it "funnel" down to the other domains in the Active Directory tree.

I still see administrators and organizations try to explain that they have an environment different than what is possible. With that said, I'd encourage all of the admins and organizations that think they have a different configuration for passwords to "test" what they believe. Unless you have a third-party product in place or have Windows Server 2008 native mode domains, you can't have anything but what I detailed here.

Possible Settings in the Password Policy
When you edit a standard Group Policy Object (GPO) from the Group Policy Management Console (GPMC), you'll find the same options for the Account Policy. To find the password policy settings, which are under the Account Policy, open up the following path of policy folders: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies. Once there, you'll find three policy folders: Password Policy, Account Lockout Policy and Kerberos Policy.

For each of these folders and the settings contained within them, there's a default in Windows Server 2003, Windows Server 2008 and Windows Server 2008 R2 freshly installed domains. The default settings are as shown in Table 1.

Limitations of the Password Policy for Domain Users
To ensure you understand what I mean by domain users, let's scope out where these users reside. Domain users are those users that are created and stored in the Active Directory database. This means all users stored on your domain controllers (DCs) fall under this definition. One easy way to see whom this entails would be to open up the Active Directory Users and Computers (ADUC) and do a search on all users for that domain. Every user that shows up on that search falls into this scope.

The only way to control the password policy for domain users is to configure the aforementioned Account Policy in a GPO linked to the domain. That is the only way by default! Yes, it's true the GPO that contains the default password policy settings is the Default Domain Policy, but this is just the default. You can easily create a new GPO, configure the Account Policy settings as you wish and ensure this GPO has the highest precedence in the GPMC. The result will be that this new GPO will control the Account Policy settings for all domain users.

Default Password Policies
When you install a new Active Directory domain within Windows Server 2008 or Windows Server 2008 R2, or upgrade a Windows 2000 or Windows Server 2003 domain to have Windows Server 2008 or Windows Server 2008 R2 DCs, you can configure the domain to be at the Windows Server 2008 Domain Functional Level. At this functional level, you have more capabilities for configurations within the domain, but that doesn't mean that the default behavior changes. This is the case with the Account Policies for domain users.

When you have a basic Active Directory domain that's running at the Windows Server 2008 Domain Functional Level, the Account Policies for all domain users behave the exact same way they always have. A Windows Server 2008 or Windows Server 2008 R2 Active Directory domain, without FGPPs implemented, has the following characteristics for passwords affecting domain users:

• The Default Domain Policy defines the password policies by default for every user in Active Directory and every user located in the local SAM on every server and desktop that joins Active Directory.
• There can be only one password policy for domain users using Group Policy.
• It's not possible to configure the password policy in a GPO linked to an OU to affect users in the OU differently than other users in the domain or in a different OU.
• The password policy settings can't be extended to include additional settings without using a third-party tool or developing a custom password policy solution.
• It's not possible to configure a password policy for the root domain and have it "funnel" down to the other domains in the Active Directory tree.

Notice that the bullet list here is very similar to the list that was at the beginning of this article. The reason is that the Account Policy and password policy, even for Windows Server 2008 R2 domains, behave the exact same way as previous Windows 2000 and 2003 domains by default.

FGPPs
The preceding section was clear in stating that the default behavior of the Account Policies in a Windows Server 2008 and Windows Server 2008 R2 domain is exactly the same as it is in any other Active Directory domain before it. The difference comes when the Active Directory domain contains only Windows Server 2008 or Windows Server 2008 R2 DCs, and is moved to Windows Server 2008 Domain Functionality Level. When this occurs, it opens the door for FGPPs. Again, just to reiterate, without FGPPs configured, any Windows domain (including Windows Server 2008 R2 domains) acts the same as it always has.

The reason you'd want to configure FGPPs is to allow multiple password policies in the same Active Directory domain. Yes, that's correct. The same Active Directory domain can have multiple password policies. The result could be the following:

• IT employees have a minimum character limit of 20
• HR and finance employees have a minimum character limit of 15
• Standard employees have a minimum character limit of 10

In order to configure FGPPs, you won't be using Group Policy -- FGPPs don't use Group Policy. Instead, the implementation of FGPPs is done by modifying the Active Directory database. The database is altered by adding one or more additional Active Directory objects, referred to as Password Settings Objects (PSOs). This might sound odd, and I must agree it is. If you decide to implement FGPPs, you'll have a mixture of Account Policy settings, via GPOs and FGPPs, in your environment.

To complete the configuration of your FGPPs, you'll need to complete the following steps:

1. Launch ADSIEDIT.MSC on your DC.
2. Select the View toolbar menu option, then click on the Connect to option.
3. In the Connection Settings dialog box click the OK button (see Figure 1).
4. Within ADSIEDIT, expand the view of your domain down to the CN=System, so you can see the contents available under this node.
5. Right-click on the CN=Password Settings Container.
6. Select the option to Create | Object.
7. Fill out the values for each entry; Table 2 is a guide.

[Click on image for larger view.]

Figure 1. ADSIEDIT connection options.

Note that the values inputs for minute/hour/day in Table 2 seem very odd. This is due to the fact that they're input in the "18" data type. The 18 data type follows an odd format, which can be seen in Table 3.

In order to link the FGPP/PSO to the correct user or group, you'll need to configure an object attribute. In order to see the correct object attribute, ensure the FGPP/PSO in ADUC or ADSIEDIT is set properly, which can be seen in Figure 2.

[Click on image for larger view.]

Figure 2. FGPP/PSO filter settings to see correct attributes for setting up permissions.

In the attribute list for your FGPP/PSO, scroll down to the msDS-PSOAppliesTo entry and double-click this attribute to see the Multi-valued Distinguished Name With Security Principal Editor dialog box, as shown in Figure 3.

[Click on image for larger view.]

Figure 3. Multi-valued Distinguished Name With Security Principal Editor for FGPP/PSO.

You can enter a domain name, username or security group into the editor. Select the correct button, then add in your object to the editor. I added the HR group, as shown in Figure 4.

[Click on image for larger view.]

Figure 4. HR group added to the HRPasswordPolicy FGPP/PSO.

Verify that user in the HR group has the correct password policy by viewing the user account properties from within ADUC, then looking at the msDS-ResultantPSO attribute.

A New Path
The default password policy settings for a Windows Active Directory domain haven't changed for the past 11 years, and in a default Windows Server 2008 R2 domain they're the same to begin with. The Default Domain Policy controls all domain user password policies by default but can be altered by another GPO linked to the domain with higher precedence. Once the domain is configured to be a Windows Server 2008 Domain Functional Level domain, FGPPs can be used.

You can use ADSIEDIT.MSC to create and configure one or more FGPP objects or PSOs, which will now allow you to have multiple password policies in the same domain. The FGPPs/PSOs will be associated with a domain name, user or group -- and have nothing to do with Group Policy, which you've known password policies to rely on for the past 11 years. Now you can obtain that segregation of password lengths for the different users in your single Active Directory domain.