In-Depth

Manage and Administer Groups in Active Directory: Part Two

In part two of a series, find out how you can simplify the management of organizational changes in Active Directory with minimal effort.

• By Danielle Ruest and Nelson Ruest
• 07/13/2005

For This Solution: Windows 2000 Server or Windows Server 2003, Active Directory

In part 1 of this series (read Manage and Administer Groups in Active Directory, Part 1 ", Windows Server System Magazine, Jan. 10, 2005), we identified how to use group scopes and how to name groups within your Active Directory. We also highlighted techniques you can use to hide information—sensitive information, in particular, such as privileged accounts and groups—within the directory. In this article we will demonstrate how and why you should manage group ownership as well as which types of groups you should populate in your directory. Use these best practices to make sure your directory groups are set correctly.

Group Ownership Management
One of the most crucial aspects of group management is the assignment of managers for each group. Group managers are responsible for the management of group content, so this is a key part of your delegation strategy. Because a global group is the only group type that contains users, and because permissions are assigned only to Global groups by including them in the proper domain local or local group, who manages group content doesn't matter. You can save yourself a lot of time if you can delegate the actual management of who belongs to a group. This way, users in your organization can manage multiple-duty groups—groups that allow access to certain network content based on access rights, groups that are used as distribution lists in your e-mail system, groups that list all the people within a department, and so on—which frees you from having to do it and makes one less task for you to manage. After all, how do you know whether so and so is in the Finance group? It's better to let the experts deal with this.

In Active Directory, group managers map out to individual accounts. When you identify a group manager, you locate a user account in your directory and assign the manager's role to this user (see Figure 1). Because the manager role is assigned to an individual account, you'd think when a manager changes you must modify the ownership of each group he or she managed. Fortunately, Active Directory provides a way to do this automatically.

Although people work with the user on the basis of the account name, Active Directory does not. It identifies all objects through special numbers—the Security Identifier (SID) and the Globally Unique Identifier (GUID). Security principals (or user accounts) are identified through their SID. When a manager changes roles and you deactivate his or her account and create a new one, you must reassign all the permissions and user rights to the new account because they are attached to the SID, not the account name. But if you simply rename a manager's account, rather than deleting it and re-creating a similar one, all the permissions of the original account remain intact. This means you can treat user accounts as user roles within your organization instead of representing specific individuals. If you do this, you can take advantage of Active Directory features to facilitate your work.

To do so, deactivate and rename accounts instead of re-creating them. For example, say that Ruth Becker, group manager for the PR global security group, leaves the company. Because you know your organization will not operate without someone in Ruth's role, you should only deactivate it rather than delete it. A few days later, John Purdy is hired to replace Ruth. Now you can assign Ruth's old account to John Purdy, reactivate it, reset the password, and force a password change at the next logon. Now John automatically has all of Ruth's former rights and permissions; in other words, he inherits all the rights and permissions that come with this new role within the organization rather than those associated with a specific person. In addition, John can access all of Ruth's documents and data, which he will need to continue the projects Ruth had started.

This also applies when a person changes positions within the organization. Here, you must cascade the accounts. When a person moves from team leader to group manager, you reassign their original account to the person moving into the team leader position, and then you repeat this step with the person the new group manager is replacing. This saves a lot of time. Compare this to modifying the access rights for the person's existing account to give them new access rights, placing them in the proper groups, letting them take ownership of the pervious manager's documents, and so on. The latter strategy only works in one of two situations: Either you're extremely well organized and your security group strategy is entirely role-based, or you've completely automated identity management in your directory. Few people have either situation in place.

If you're one of the many who don't fall into those two categories, you'll find renaming accounts is by far the simplest strategy. It's completely transparent to users because they work with names and not SIDs. In addition, the advantages of renaming the account are great for system administrators because you only have to perform a few tasks to complete the process.

In some cases, security officers will be against this practice because they fear they will not be able to track user activity within the network, and they are partially correct. Because Active Directory tracks users through their SIDs, the SID is the only value guaranteed when you view audit reports. So when you change a user's name, you are continually reusing the same SID. Therefore, you must maintain strict records to track when usernames for an SID are modified because otherwise you will not know who owned that SID prior to the current user. Worse yet, you won't know when the current user became owner of the SID, which could cause problems for the new user, especially if the former owner performed some less-than-honest actions under this SID before leaving the position.

Best Practices for Global Group Management
Now you're getting your group management strategy together. You know global groups are the only groups that contain users. You've mapped them out to domain local or local groups, so you know how the access rights are assigned. You also have identified where you need security groups vs. distribution groups. You know if a security group can double up as a distribution group, and you've reduced the number of groups you need in the directory.

Now you need to think about the types of global groups you'll need. In most enterprise networks, the global groups you create will fall into four specific categories: IT roles, line-of-business groups, project-based groups, and special administrative groups.

IT Roles: These identify a person's IT role within the organization. IT roles include a variety of different activities. Examples of these group types include: generic information worker; management and management support; professionals; end user developer; Web/Intranet editor; Webmaster; system developer; systems or security administrator; and systems and user support.

These IT roles let you create horizontal user groupings that span your organization and allow you to manage people who perform similar tasks, both within the organization and within your Active Directory structure, no matter where they are located. These roles are useful because they support software distribution and system allocation—every person in any given role should have the same products on their system. For example, all Webmasters need Web editing tools, all developers need development tools, all professionals need productivity tools, and so on. To keep this system at its best, you should try to limit these roles to less than 20. For example, one organization that has more than 4,000 users should have only nine IT roles defined within its network.

Line-of-Business Groups: In most cases, you also will need to manage users vertically. For example, if the Finance department wants to contact all its members, a Finance global group will be required. Many of these groupings will have been created with the Organization Unit structure in your domain, but you cannot use an OU to send e-mail messages. Thus, a group will still be required. In addition, many departments have personnel distributed in a vast number of OUs, especially if your organization includes regional offices and you need to delegate regional management activities. Try to keep these groupings to a minimum as well. In many organizations, the "Department Minus 1" rule is all you need. This means you follow the hierarchical structure of the company to one level below departments. So in the Finance department, you would find the Finance group, then Accounts Payable, Accounts Receivable Payroll, Purchasing, and so on. You may require a more detailed division for your groups within special departments, such as the IT department itself.

Project-Based Groups: Organizations are constantly running projects. Each project often is composed of different people from different departments in the organization. Projects are volatile and last usually for definite periods of time, so, unlike IT roles and line-of-business groups, project-based groups are not permanent. Therefore, this group type is the one that gives you the most work. It is also because of this that this group type might involve the creation of other group scopes—not for the inclusion of users, but rather for the assignment of permissions to project resources. Once again, try to keep a tight reign on how many you create in this area.

Special Administrative Groups: The last global group type is the special administrative group. Like IT roles and line-of-business groups, this group type is more stable than project groups. It is, however, required to support the application of special administrative rights to groups of users and is designed to support your delegation strategy. For example, if you need to filter group policy or assign specific group policy features through the use of security groups, you would do so through a special administrative group.

Whichever group type you create or manage, remember the key to a successful group management strategy is documentation—both inside and outside the directory. Document your groups within the directory using the group manager and include group descriptions (see Figure 2). Also, document your groups outside the directory through external databases and other documentation methods (see Table 1). It is a good idea to turn this table into a proper centralized Microsoft Access database to ensure all group operators refer to it whenever a new group needs to be created.