Nov 12
Granular Password Policies
Erik Gilreath
Starting with C/D/H in 1999, I’m coming up on my 10 year anniversary. I’ve had a great time learning many different technologies. I’ve been focused recently on Server 2008, Hyper-V, Citrix XenApp, System Center Configuration Manager and have dabbled some in Novell SecureLogin.
When I’m not working, I enjoy playing softball, running, spending time with my kids, working with our three horses and just puttering around the house.
More about Erik
Articles by Erik Gilreath
One of the new features of Active Directory in Server 2008 was the ability to create a granular password policy. Prior to this, password policies could only be applied at the domain level. This meant that if you needed to have multiple enforceable password policies, you were required to have multiple domains – one for each password policy that was required. With the addition of granular password policies, you can create several different policies and apply them to individual users or groups. This allows a lot more flexibility for administrators.
Server 2008 R2 has taken the granular password policy and made it even easier. The password policies that could be created in Server 2008 were quite confusing to setup and deploy. Dates and times had to be converted to the number of nanoseconds (e.g. 1 day = 864000000000 nanoseconds). In addition, to assign the policy to an object, you had to provide the distinguished name of the object – there was no built-in search utility. With R2, you enter date values in a dd:hh:mm:ss format where dd is the number of days, hh is the number of hours, mm is the number of minutes and ss is the number of seconds. Also, for assigning a policy to an object, the regular AD search box is now provided.
Another thing to note with granular password policies – one of the variables is Password Settings Precedence. This is essentially the “cost” of the policy. In the case where multiple password policies are assigned a user, the policy with the lowest cost wins. Keep this in mind when creating policies. More restrictive policies should have lower costs.
When creating new policies, be sure to leave room to add policies in the future (e.g. start numbering at 10, 20, 30, etc.) If you decide to manage everyone with granular password policies, it is recommended to set the default domain policy to an almost annoying security level in case someone gets missed and doesn’t have a password policy assigned to them. If the default policy is very restrictive, the user will call and ask to have it changed. If the policy is loose, they won’t want to be put in a more restrictive one and won’t notify anyone.
Hopefully this has given you a little more insight into granular password policies. Here’s a link to a step-by-step video on creating them in R2: http://www.ditii.com/2009/09/05/windows-server-2008-r2-configuring-granular-password-settings. This is a long-awaited and powerful addition to Active Directory that should be a great help in making accounts more secure.