The Low-Down on Password Policies

Below we will be looking at password policies in detail as this can get confusing in some circumstances. I will cover generic domain password policies as well as the new server 2008 granular Password Settings Objects (PSO's). There are many articles on the Internet around password policies for windows networks. The reason for writing this is I have found many of the articles are missing some key points that are very important! These missing points will be my main focus in this post.

Where do I link the password policy?

Many of the articles on the Internet discussing password policies describe how to configure the password security object but not where to link it and why. Password policies are applied to computer objects not user objects in active directory. There can only be one password policy "per account database".

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

If you were to link your password policy to the "Domain Controllers" OU, this would mean that your password policy would apply to active directory and all user accounts in Active Directory.

If you were to link your password policy at 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 organisational unit. The password policy will hit the local SAM database for all member workstations in the active directory domain meaning that not only will active directory accounts use the password policy but also machine-local accounts on member workstations will also now need to adhere to the password policy.

Microsoft recommends always linking your password policy at the root domain level to ensure the policy covers local accounts as well as active directory accounts for obvious reasons. It is silly having a strict password policy for your domain user accounts but not for your local user accounts. If someone cracked a local user account on a member workstation they could still rootkit a PC which they could then use as an access point to attack the active directory domain.

Here is a quick structure from Microsoft on where to link your policies:

Default Domain Security Policy Settings:
- Password Policy
- Domain Account Lockout Policy
- Domain Kerberos Policy

Default Domain Controller 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 to 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.

I want to see who is Logging in and out in my Domain?

This is not part of password policies, this is actually an audit policy. Audit policies need to be configured on the Domain Controllers OU as I mentioned above. This Microsoft article describes what policies should be configured on the domain root level and which policies need to be configured.

Two audit policies I want to draw attention to are "Audit logon events" and "Audit account logon events" as they cause much confusion.

"Audit account logon events" are when user accounts try to authenticate against a domain controller. It can log success or failure depending on how you configure it. This basically checks the users credentials are correct (right username and password).

"Audit logon events" generates events for the creation and destruction of logon sessions. For example things that trigger these events are things like accessing a share. Your already "authenticated" on the network, your just using your kerberos key to access network resources.

For information on the various audit policies see this post:

http://www.enterprisenetworkingplanet.com/netos/article.php/624921

I recommend only configuring audit policies you need. Do not audit everything, if so your event logs will be spammed. Personally I only audit "Account logon events" as I only want to see when people logged in and out of the network, and any failed logon attempts.

So what are these Password Settings Objects in Server 2008?

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 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 refered 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. It is there more as a fallback encase the PSO does not get applied to particular users.

If you want a step by step guide on how to configure Password Settings Objects 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