Manage and Administer
Groups in AD — Part One
Learn to manage and control user group proliferation in your network.
by Danielle Ruest and Nelson Ruest

January 10, 2005

Editor's note: This article is the first of two parts that will help system administrators reduce group management overhead in a directory.

Windows system administrators get much practice working with groups and group scopes, whether it's within NT domains or in Active Directory (AD) forests. Group usage is not new, but it's surprising to see how few organizations use groups appropriately in their directories. One of the most important purposes of groups is both the assignation of permissions within the directory as well as permissions to access objects outside the directory, such as printer queues and file folders.

In fact, one of the first best practices you learn in any network environment is that you never assign permissions to individual users; you always assign them to groups. It's simple; assigning permissions is a complex task. If you assign permissions to a user and the next day another user comes along who requires the same permissions, you have to start over from scratch. But, if you assign permissions to a group, even if there is only one person within the group, and another user comes along requiring the same permissions, all you need to do is place the user within the group.

This strategy works only if you have complete documentation about each of the groups you create in your directory. It's easy to include users into an existing group if you created the group yesterday and today someone requires the same rights. But, if you created the group last year and someone requires the same rights today, chances are that you might not remember that the original group even exists. This problem is compounded when group management is distributed. You might remember why you created a specific group, but other group administrators won't have a clue the group even exists unless you tell them.

This lack of communication usually leads to a proliferation of groups within the organization. Here's why. Admin 1 creates a group for a specific purpose. Admin 1 places users within the group. Admin 2 comes along a while later with another request for the same rights. Admin 2 does not know that the group Admin 1 created exists. So, just to be safe, Admin 2 creates a new group for the same purpose, and so on. Most organizations that don't have a structured approach for group management will find they are faced with massive group proliferation. In these organizations, it's not unusual to find that they can have as many groups as they have users. Now that can't be very practical, right?

The best way to avoid this type of situation is to document all groups at all times—identifying who is responsible for the group, including a group description, listing the group purpose, and so on—and to make sure that this documentation is available to all affected personnel at all times. Active Directory provides the ideal solution. Group management in AD is simplified because the group object supports several new properties that assist in the group-management process:

• Description was present in Windows NT, but it was seldom used. Use it fully in AD.
• Notes is used to identify the full purpose of a group. This information provides great help in long-term group management. Both Description and Notes are on the General tab of the Group Properties dialog box.
• Managed by is used to identify the group's manager. It includes the "Manager can update membership list" checkbox. Checking this box lets you know who is responsible for the group at all times.

Filling out these fields is an essential aspect of a proper group-management strategy. This rule applies to both security and distribution groups in AD.

Best Practices for Group Management
Group-management practices can become quite complex, so a group-management strategy is essential to the operation of an enterprise network. This strategy begins with best-practice rules and guidelines. It is complemented by a strategic use of global groups or groups that are designed to contain users. As in Windows NT, AD users are placed within global groups and only within global groups. Use the AGLP rule to create and manage groups in AD (see Figure 1). AGLP stands for "domain Accounts go in Global groups, global groups go in Local groups, and local groups are assigned Permissions." AGLP follows these rules:

• Global groups only contain users.
• Domain local or local groups only contain other groups (global or universal).
• Permissions are assigned only to either domain local groups or local groups.
• Universal groups only contain global groups.

This rule is supported by these additional guidelines:

• All group names are standardized.
• All groups include detailed descriptions.
• All groups include additional notes.
• All group managers are identified clearly.
• Group management staff is trained to understand and use these rules.
• Group purpose verification activities are performed on a regular basis.
• A group usage report tool is in place to provide regular group content updates.

Standard Group Naming
In Windows NT, many organizations implemented a standard naming strategy for both global and local groups. It was simple; place a "G_" or an "L_" at the beginning of the name of each group type. However, groups in AD can have more complex names, so you should reconsider how you name groups. You should also take into consideration the possible delegation of group membership management.

For example, if your public relations department wants you to create a special group that they will use to both assign file and folder permissions and communicate with all PR managers within the enterprise, you might decide that you don't want to be burdened with the day-to-day administration of the contents of this group once you create it. As such, you could delegate global group content management to someone in the PR department. You could do this for a vast number of departments. And only global groups contain users, so you only need to consider the delegation of global groups. This lets you retain the management of domain local and universal groups, and as such, retain control over the permissions and rights you assign to any user in the organization.

In addition, remember that users can search the directory. In an enterprise network, you'll want to keep a tight rein on the creation and multiplication of groups. Therefore, your core strategy should focus on combining group functions as much as possible. For example, if you integrate Microsoft Exchange to your directory, you will need to manage many more distribution groups. But if your security group strategy is well defined, then several of your existing security groups will double as distribution groups. This means that you should have considerably less distribution groups than security groups. You might not even have to create any new distribution groups at all if you've done your homework right. You should also reconsider your group-naming strategy. Everyday users won't be comfortable with groups named G_PRMGR or L_DMNADM. A proper group-naming strategy should take into account these guidelines:

• Global groups should be named without identifying their scope. Scope identification is displayed within the directory automatically.
• Global groups should be named using common language because they might be accessed by users for communication purposes or by user representatives for membership-management purposes.
• Down-level names should not include scope for global groups because users can also access the down-level name.
• Universal groups should include the organization's name to identify that they're forest-wide groups.
• Domain local groups should be named including the "(Local)" identifier at the end of the name. This allows administrators to search for all local groups more easily.
• Down-level names for domain local groups should be preceded by an "L_" to make them simpler to identify in the directory.
• All domain local and possibly universal groups should be contained within organizational units (OU) that deny read rights to common users. This ensures that user directory query results never include domain local or universal groups and always only include groups to which they have access. Special groups such as domain admins, enterprise admins, schema admins, and Administrators should be moved to containers that deny user read rights so that users cannot locate these special security roles in your organization.

Following these naming strategies greatly reduces your group management headaches. These naming strategies, along with the guidelines outlined previously, should produce these results:

• Universal groups are the fewest in number. They are used only for extremely special purposes.
• Domain local groups are fewer than global groups. Permissions are assigned to domain local groups, so you should be able to create a smaller number of these groups. Certain groups that might need to be segregated on user membership can nevertheless be assigned the same permissions.
• Global security groups should be the most numerous group type in your forest. These groups should perform double duty as both security and distribution groups.
• Global distribution groups should be less numerous than global security groups. Distribution groups should be used only if there is no corresponding security group that can fulfill the same purpose.

Keep to these results. Group management requires tight controls, especially if it is a delegated task. Use a group creation process flowchart to simplify your group-management activities (see Figure 2).

About the Authors
Danielle Ruest and Nelson Ruest (MCSE, MCT) are prolific authors that try to make system administration an easier world to live in. They are the proud authors of Windows Server 2003 Pocket Administrator, the only administration guide you shouldn't be without. Feel free to send comments or questions to .