Fine-Grained Password Policies, Part I

One of the thorns in the side of network designers for years has been the fact that you can only have one set of password and account-lockout policies per domain. Ever since Organizational Units (OUs) made it possible for organizations to build really large domains, one upper limit on domain size has become the number of people and departments we can get to agree on a single set of requirements for AD passwords. Server 2008 includes a feature for deploying multiple sets of password policies within a single domain. It requires that all domain controllers in the subject domain be running Server 2008 – i.e., that your Domain Functional Level (DFL) be “Server 2008.” (Hey, at least you don’t have to have every DC in the forest running Server 2008 R2, as is the case with the Active Directory Recycle Bin.) This would seem to be a pretty handy capability for organizations with really large domains – or that have departments with widely differing opinions as to where to draw the boundary between convenience and security when it comes to password requirements. However, leave it to Microsoft to take a good idea and nearly spoil it with a clunky implementation. The main problem with these “fine-grained password policies” is that Microsoft has designed them to be linked to security groups instead of OUs. So instead of leveraging AD structures that you already have in place, Microsoft wants you to create new structures – new groups – to which your fine-grained password policies will apply. Sure, you can simply design the groups so that they mirror an OU’s membership; Microsoft calls these groups “shadow groups.” But you have to manage these groups if you want them to continue to “shadow” your OUs as OU members change over time. That is, when you move a user account from one OU to another, you also have to change the membership of your shadow groups. Just what we need: more administrative chores!