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.

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.

Policy Setting Default Setting Value
Enforce password history 24 days
Maximum password age 42 days
Minimum password age 1 day
Minimum password length 7
Password must meet complexity requirements Enabled
Store passwords using reversible encryption Disabled
Account lockout duration Not defined
Account lockout threshold 0
Reset account lockout counter after Not defined
Enforce user logon restrictions Enabled
Maximum lifetime for service ticket 600 minutes
Maximum lifetime for user ticket 10 days
Maximum lifetime for user ticket renewal 7 hours
Maximum tolerance for computer clock synchronization 5 minutes

Table 1. Account Policy settings default values.

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.


Attribute Value Explanation
Cn HRPasswordPolicy The name of the password policy object in Active Directory. Should be named after which user group it will affect.
msDS-PasswordSettingsPrecedence 10 A reference number, compared to other precedence settings for other FGPPs, which will resolve a conflict if user is member of two groups and each group has an FGPP. Smaller numbers have higher precedence.
msDS-PasswordReversibleEncryptionEnabled False Boolean value to define if passwords should be stored with reversible encryption.
msDS-PasswordHistoryLength 24 Number of unique passwords user must input before reusing a password.
msDS-PasswordComplexityEnabled True Defines if password complexity should be enabled or not.
msDS-MinimumPasswordLength 15 Minimum number of characters in each user password.
msDS-MinimumPasswordAge -864000000000 Minimum password age (one day).
msDS-MaximumPasswordAge -36288000000000 Maximum password age (42 days).
msDS-LockoutThreshold 30 Number of failed password attempts before user is locked out.
msDS-LockoutObservationWindow -18000000000 Elapsed time to reset password lockout counter to maximum (in this case 30 minutes).
msDS-LockoutDuration -18000000000 If the number of bad passwords is met in observation window time, this defines how long the account should remain locked out (30 minutes).

Table 2. FGPP/PSO values to create a new object.

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.

Time Unit Formula Example Time Value
m minutes -60*(10^7) = - 600000000 30 minutes -18000000000
h hours -60*60* (10^7) = -36000000000 10 hours -360000000000
d days -24*60*60*(10^7) = -864000000000 42 days -36288000000000

Table 3. The "18" data type formatting for minutes, hours and days.

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.

comments powered by Disqus

Reader Comments:

Wed, Mar 20, 2013 orlando Cuba

my Active Directory domain contains only one server with Windows Server 2008 DCs, and was moved to Windows Server 2008 Domain Functionality Level. this server 2008 was upgraded from server 2003. My problem is that my previus GPO and new GPO that i create not workin in my cliens pc.

Wed, Mar 13, 2013 Frank

Don't be confused by the person who mentioned fine grained password polices. That's ADFS which is irrelevant.

Sun, Dec 2, 2012 khaled 1

Minimum password age 1 day

Wed, Sep 12, 2012

why locked instantly repeatedly after unlock application linked to another windows logon

Thu, May 31, 2012 brian

in server 2008, if we start to enforce password complexity are we going to need to reset a bunch of passwords? When we moved everyone that had an account that was set to never expire, and we changed them to expire, the password expired right then and there. is this going to be the same issue?

Fri, Mar 2, 2012 Tarkan Koemuercue Switzerland

A domain can have different password policies for each departments by creating different additional GPOs with different password settings for different groups in the root domain. If the additional password settings GPOs will not apply to the members of the groups the default domain policy with the default password settings will apply by default. There is no need to implement PSO for that case if you verify the link-order of the GPOs.

Tue, Nov 22, 2011

Good article. We're using the Hitachi-ID Password Manager product to manage our Windows AD passwords. Works great, allowing user self serve password managed (resets, unlocks), Delegated Adminstration of password management, and password synchornization (changes passwords in ERP system, mainframe, applications, relational databases, etc.).

Fri, Nov 11, 2011 Adam

Password problems are some of the biggest pain points for my IT department. HIPAA regulations require a strict password policy, but forgotten passwords and account lockouts are often a result of that very policy. Derek mentions some third-party software tools, and we are beginning our search. I just downloaded the free trial of netwrix password manager (there's also a freeware version for up to 50 users), and it looks promising. Anyone have any other password management tools worth evaluating?

Thu, Sep 22, 2011 Darren London

or if you didn't feel comfortable about using ADSIEDIT or the hex values you could use a free tool by Specops Software, Password Policy Basic http://www.specopssoft.com/documentation/specops-password-policy-basic-documentation Or if you want to take your password policy above and beyond Microsofts offering, look at the full product, Specops Password Policy http://www.specopssoft.com/documentation/specops-password-policy-documentation

Fri, Aug 26, 2011 Chris Massachusetts

Great article. Is there any way though after the ADSIEDIT customizations to reveal these differences from GP or ADUC (besides checking individual users affected by the GP)? Do clients or anyone asking for this level of detail express concerns over ‘loosing track’ of who’s got the most/least aggressive password settings? Do you have a gauge or guidelines on at what point using a 3rd-party tool may be more manageable? Chris Rich Product Manager NetWrix Corporation NetWrix is #1 for Change Auditing: Simple, Lightweight, Affordable

Thu, Aug 25, 2011

You can use fine grained password policies. http://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx

Thu, Aug 25, 2011

Outstanding article

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.