Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies
Updated: August 24, 2007
Applies To: Windows Server 2008, Windows Server 2008 R2
Group-based management of fine-grained password and account lockout policies involves the following steps:
Step 1: Create all necessary Password Settings objects (PSOs). For more information, see Step 1: Create a PSO.
Step 2: For every existing PSO, create a corresponding global security group. For more information about creating groups, see Create a new group (http://go.microsoft.com/fwlink/?LinkId=98721).
Step 3: Apply all PSOs to their corresponding global security groups. For more information, see Step 2: Apply PSOs to Users and Global Security Groups.
Step 4: Assign appropriate permissions on your PSO-corresponding global security groups to the selected users or groups (delegated administrators) from your organization. For more information, see Assign, change, or remove permissions on Active Directory objects or attributes (http://go.microsoft.com/fwlink/?LinkId=98723).
A group-based approach is the recommended solution for the most effective management of fine-grained password and account lockout policies because the direct management permissions over the attributes of PSOs are retained only by the members of the Domain Admins group. Members of this group can revisit and revise existing fine-grained password and account lockout policies when necessary, based on the changes in their organization.
This approach ensures fewer sporadic changes to the fine-grained password and account lockout policies because the delegated administrators—for example, technical support specialists—can manage fine-grained password and account lockout policies only by attesting that all appropriate PSOs are applied to their corresponding global security groups. In other words, delegated administrators do not have permissions over the PSO attributes. They cannot, for example, add a universal group or a domain-local group to a PSO's msDs-PSOAppliesTo attribute—an erroneous action that will not have any effect on the PSO. Neither can they commit the error of adding a universal group or a domain-local group to the PSO-corresponding global security groups that they have the permissions to manage because, by design, global security groups allow as members only other global security groups or users from the same domain.
The privilege of assigning exceptional PSOs that take precedence over all implicit PSOs that are applied to the group that the user is a member of is also retained only by members of the Domain Admins group. This contrasts with various exceptional PSOs being assigned to users or groups by multiple delegated administrators, which can eventually lead to a complicated and possibly convoluted PSO structure.
The risk of introducing errors in PSO precedence values (for example, more than one PSO with the same value applied to the same user object) is also significantly decreased when only members of the Domain Admins group have the permission to manage PSO attributes directly.