How and Where to Configure the Domain Password Expiration Policy in 2003 / 2008 Active Directory; A Must Read for any Windows System Administrator.

Updated March 20, 2010
*Content for this guide was provided with permission by Clint Boessen, MCSE, from his original article "The Low Down on Password Polices". Visit Clint's blog site at http://clintboessen.blogspot.com/ for more topics and information related to Active Directory and Exchange.


Summary
In this guide we will cover some of the important "where, how and whys" of setting up the domain password expiration and lockout policies in AD 2000, 2003, 2008 as well as the new granular Password Settings Objects (PSO's) available in 2008 Active Directory. There are many articles on the Internet with information on setting up password policies for windows networks, however most of these articles do not cover several key points which are vital to ensuring these extremely important policies are set up and applied correctly. These commonly missing key points will be the main focus, and by the end of this guide you should have enough of an understanding to be able to set up these policies in your own environment.
We would like to advise a strong word of caution, however, before making changes to policies in Active Directory. Enabling the password expiration policy in an existing domain without first formulating a sound game plan can be a nightmare for your users and IT staff. Review our guide here for a few basic password policy deployment approaches that can save you some time and headache.




Contents


Where do I link the password policy and lockout policy in the domain tree?
Do I create a new GPO or use the existing default group policy objects?
So what are these Password Settings Objects in Server 2008?
Audit Policies - How to see who is logging in and out of the domain

Where do I link the password policy and lockout policy in the domain tree?

The domain password expiration policy, lockout policy, and other related policy settings must be configured at specific locations within the AD tree structure in order to function properly. Password policies are applied to computer objects, not user objects in active directory. There can only be one password policy "per account database", e.g. "per domain". This holds true for 2000 through 2008 domains.

Microsoft says:

There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand alone computers. There can be only a single password policy for each account database. An Active Directory domain is considered a single account database, as is the local account database on stand alone computers.

Taken from: http://technet.microsoft.com/en-us/library/cc875814.aspx

Scenario 1: If you were to link your password policy to the "Domain Controllers" OU, this would mean that your password policy would apply only to domain user accounts in Active Directory.

Scenario 2: If you were to link your password policy at the root domain level, this would hit all computer objects in the active directory database including domain controllers (assuming you do not have block policy inheritance set on the domain controllers organizational unit). The password policy will hit the local SAM database for all member workstations / servers in the active directory domain, meaning that in addition to domain user accounts using the password policy, all machine-local user accounts on domain member workstations and servers will also now adhere to the domain password policy.

Microsoft recommends always linking your password policy at the root domain level (Scenario 2) to ensure the password policy uniformly covers local machine user accounts as well as active directory domain user accounts for obvious reasons. Think about it- Why enforce a strict password expiration policy for your domain user accounts but not for your local user accounts? If someone cracked a local user account on a member workstation or server they could install a rootkit, which they could then use as an access point to attack the active directory domain. If your company is under current compliance requirements for SOX, PCI, HIPAA, etc, more than likely you will need to apply your password expiration policies at the root level. Check your compliance requirements to confirm.

The above scenarios also hold true for the domain lockout policy. Also note that child domains of the parent root domain must have their own separately configured polices. Here is a quick "Best Practice" structure from Microsoft on where to properly link your different policies:

Default Domain (root level) Security Policy Settings:
- Password Policy
- Domain Account Lockout Policy
- Domain Kerberos Policy

Default Domain Controller (Domain Controllers OU) Security Policy Settings:
- User Rights Assignment Policy
- Audit Policy

Taken from: http://technet.microsoft.com/en-us/library/cc773164.aspx

Do I create a new GPO or use the existing default group policy objects?

Microsoft recommends never modifying the "default domain policy" and "default domain controllers policy". Create a new group policy object called something like "Corporate Password Policy" and link it at the root domain level. Ensure to assign it a higher priority than the Default Domain Policy to ensure the settings override.

Taken from Microsoft:

It is a best practice to avoid modifying these built-in GPOs, if you need to apply password policy settings that diverge from the default settings, you should instead create a new GPO and link it to the root container for the domain or to the Domain Controllers OU and assign it a higher priority than the built-in GPO: If two GPOs that have conflicting settings are linked to the same container, the one with higher priority takes precedence.

Reference: http://technet.microsoft.com/en-us/library/cc875814.aspx

The reason behind this is because doing so makes it much easier to recover from serious problems with security settings. If the new security settings create problems, you can temporarily disable the new Group Policy object until you isolate the settings that caused the problems.

What are these new Password Settings Objects in Server 2008 AD?

As I mentioned above, password policies apply on a database level meaning that every account in the Active Directory database needs to adhere to a password policy. In Server 2000/2003 if you want to have a different password policy for different departments or user groups, the only way to achieve this was to create another domain (or child domain) within the same forest.

Windows 2008 gets around this with the new Password Settings Objects (called PSO's for short). PSO's can be configured to effect specific users and groups in an active directory domain.

PSO's sometimes get referred to as "Granular Password Settings" or "Fine-Grained Password Policy". One thing I would like to point out, a PSO is not a policy. A PSO is an object in the active directory database much like a user account or computer account. There are two AD Classes that make this work:
- Password Settings Container
- Password Setting Objects

To use PSO's your domain functional level must be server 2008. With PSO's they do not replace your domain password policy - you still need to configure this at the appropriate level in AD. It is there more as a fallback in case the PSO does not get applied to particular users or groups.
For a step by step guide on how to configure Password Settings Objects in 2008 AD please read these two articles by Jakob H. Heidelberg from windowsecurity.com:http://www.windowsecurity.com/articles/Configuring-Granular-Password-Settings-Windows-Server-2008-Part-1.html


http://www.windowsecurity.com/articles/Configuring-Granular-Password-Settings-Windows-Server-2008-Part2.html

Audit Policies - How to see who is logging in and out of the domain

This section is not part of configuring the domain password policies, however configuring appropriate audit policies for specific events in the domain can be beneficial when you need to find key information on past events.
Audit policies should be configured on the Domain Controllers OU level.

Two audit policies which are frequently used are "Audit logon events" and "Audit account logon events". These policies can tell you who logged in (or failed login) to the domain, and who accessed which network resource (or failed to access). Since these two audit policies sound somewhat similar, it is a bit confusing on the differences between the two.

The "Audit account logon events" policy covers when user accounts try to authenticate against a domain controller. It can log success or failure depending on how you configure it. This policy basically checks that the user's login credentials are correct (correct domain username and password) at time of login to the domain.

The "Audit logon events" policy generates events for the creation and destruction of logon sessions. For example, triggers for these events are things like accessing a shared directory. The user is already "authenticated" on the network and using their issued kerberos key to access shared network resources.

For further information on the various audit policies see this post:http://www.enterprisenetworkingplanet.com/netos/article.php/624921

Tip- Only configure audit policies that you actually need. Do not audit everything, otherwise your event logs will be spammed and you will be sifting through meaningless events looking for the important items. Start with "Audit account logon events" in order to see when people logged in and out of the network as well as any failed logon attempts. From there, you can add other audit polices as required for your environment.
-End of guide


Looking for a good proactive management tool to assist with managing your password expiring users?

Password Reminder PRO

Expiring Password Reminder & User Account Auditing Software for Active Directory

Complete proactive solution to reliably notify users of Windows password expiration & expiring logon accounts. Daily event report allows admins to stay ahead of common user issues. Hot! 

Download today and reduce expired password help calls..

Need a secure, easy to deploy web based self service solution to allow user password resets and account unlocks?

Password Reset PRO
The Best, Easiest to Use Web Based Self Service Software for Active Directory Users

Our Web Based Self Service solution allows users to easily reset an expired or forgotten password, account lockout, and contact IT staff for help. Easy to deploy, no user training, highly secure!

Download the hottest solution for web based self service..