email article printer friendly more resources

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.