Group management practices can become quite complex. This is why 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. The varying scopes of all of the groups within Active Directory will not help your group management activities if you do not implement basic guidelines for group usage. Thus there is a best practice rule for using groups. It is the User-Global Group-Domain Local Group-Permissions rule or UGLP rule. This rule outlines how groups are used.
It begins with the placement of users. All users are placed within Global groups and only within Global groups. Next, Global groups are placed within Domain Local groups and mostly in Domain Local groups. Permissions are assigned to Domain Local groups and only Domain Local groups. When users need to access objects in other domains, their Global group is included within the Domain Local group of the target domain. When users need to access objects located within the entire forest, their Global group is inserted into a Universal group. This rule is illustrated in Figure 6-4.
In short, this rule is summarized as follows:
• Global groups only contain users.
• Domain Local or Local groups only contain other groups (Global or Universal).
• Permissions are only assigned to either Domain Local groups or Local groups.
• Universal groups only contain Global groups.
lhe UGLP Rule c°a Domain Access oiMSk,
User Global group Domain Local group Permissions
Forest ^roup*' |ÚÍfj) Used for F°rest"Wide Access
User Global group Domain Local group Permissions Domain Access
Figure 6-4 The UGLP rule
This rule is supported by the following additional guidelines:
• All group names are standardized.
• All groups include detailed descriptions.
• All groups include additional notes.
• All group managers are clearly identified.
• 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 names and group manager administration are two areas that require further discussion before finalizing the Group Management Strategy.
-_______.r on Web site includes tools you can use to document your group strategy at http://
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. But in Windows 2000 and WS03, groups can have more complex names. In fact, groups have three names:
• The WS03 group name, which is the name you will use to manage the group.
• The down-level group name, which is similar to the name you used in Windows NT.
• The group email address, which is how you communicate with members of a group.
Thus, you should reconsider how you name groups to make a better use of the directory. You should take into consideration the possible delegation of group membership management. For example, if your public relations department wants you to create a special group for them that they will use to both assign file and folder permissions and communicate with all PR managers within the enterprise, you might very well decide that once the group is created, you don't want to be burdened with the day-to-day administration of the contents of this group. As such, you could delegate group content management to someone in the PR department. This could be done for a vast number of groups.
Since only Global groups can contain users, you only need to consider the delegation of Global groups. Also, by retaining the management of Domain Local groups, you 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. Therefore, you should have considerably less distribution groups than security groups. You may not even have to create any new distribution groups at all if you've done your homework.
So, if you think you will be delegating Global group membership management at least for some Global groups or you think that you may one day need to have security groups, usually Global Security groups, double as distribution groups, you should reconsider your group naming strategy. Everyday users will not be comfortable with groups named G_PRMGR or L_DMNADM.
Thus an Enterprise Group Naming Strategy should take into account the following guidelines:
• Global and Universal groups should be named without identifying their scope. Scope identification is displayed automatically within the directory so this is not an issue for administrators.
• Since they may be accessed by users for communication purposes or by user representatives for membership management purposes, Global and Universal groups should be named using common language.
• Universal groups should include the organization's name to identify that they are forest-wide groups.
• Down-level names should not include scope for Global and Universal groups because users can also access the down-level name.
• 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 it simpler to identify them in the directory (once again by administrators).
• All Domain Local groups should be contained within OUs that deny read rights to common users. This will ensure that user directory query results never include Domain Local groups and always only include groups to which users should 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 identify these special security roles in your organization.
f¡I H e i p 5 e1 v: c e s G i' o u p ß^PC Technicians [Local;
Security Group - Domain Local Security Group ■ Domain Local Security Group - Domain Local Security Group - Global f^RAS and IAS Servers ¡^Central Technicians ^Common Users_
Security Group - Global
Table 6-2 lists some sample names for different groups.
T&T Public Relations Managers; T&T Technicians; T&T Administrative Assistants
Universal Group Down-level Name
T&T PR Managers; T&T Technicians; T&T Admin Assistants
Public Relations Managers; Region 1 Technicians; Region 1 Administrative Assistants
Global Group Down-level Name
PR Managers; R1 Technicians; R1 Admin Assistants
Domain Local Group
Public Relations Managers (Local); Region 1 Technicians (Local); Region 1 Admin Assistants (Local
Domain Local Group Down-level Name
L PR MGR; L R1 Techs; L R1 AdmAss
Table 6-2 Group Name Examples
Using such a naming strategy will greatly reduce group management headaches. This naming strategy along with the guidelines outlined above should produce the following results:
• Universal groups are the fewest in number. They are used only for very special purposes.
• Domain Local groups are fewer than Global groups. Since permissions are assigned to Domain Local groups, you should be able to create fewer of these groups. It should be possible to identify that certain groups that may need to be segregated on user membership should nevertheless be assigned the same permissions.
• Global Security groups should be the most numerous group type in your forest. These groups 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 security group that can fulfill the same purpose.
Keep to these results. Group management requires tight controls, especially if it is a delegated task. Figure 6-5 outlines the Group Creation Process Flowchart to simplify your group management activities.
One of the aspects of group management that is crucial to your strategy is the assignation of group managers. When you identify a group manager, you locate a user account in your directory and assign the manager's role to this user. When the manager changes, you must modify the ownership of each group. Active Directory provides an automated way to do this.
While 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) or the Globally Unique Identifier (GUID). Security principals (user accounts) are identified through their SID. When a manager changes, if you deactivate the former manager's account and create a new account, you will have to reassign all of the former account's permissions and user rights.
If, on the other hand, you treat user accounts as user roles within your organization instead of individuals, you can take advantage of Active Directory features to facilitate your work. To do so,
Create Group ' Group "
Contain Users or Computers?
i— Yes Group Scope
Forest-Wide —Yes-> Universal"
Computer or v .
Server only "Yes- Local
Domain only—YesDomain Local -j.
Will the group support permission assignation?
Figure 6-5 The Group Creation Process Flowchart you need to deactivate and rename accounts instead of recreating them. For example, Ruth Becker, group manager for the PR Global Security group, leaves the company. Since you know that your organization will not operate without someone in Ruth's role, you do not delete her account, you only deactivate it. A few days later, John Purdy is hired to replace Ruth. Now you can reactivate Ruth's old account, rename it to John Purdy, reset the password, and force a password change at next logon. John automatically has all of Ruth's rights and permissions or rather, all the rights and permissions that come with his new role within the organization.
This even applies if a person only changes positions within the organization. Once again, since people work with names and AD works with SIDs, using a new account or a renamed account is completely transparent to them. On the other hand, the advantages of renaming the account are great for the system administrator because you only have to perform a few tasks and you're done.
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. They are right in a way. Since AD tracks users through their SIDs, the SID is the only value that is guaranteed when you view audit reports. When you change a user's name, you are continually reusing the same SID. If you do not maintain strict records that help you track when the user name for a SID was modified, you will not be able to know who owned that SID before the current user. Worse, you won't know when the current user became owner of the SID. This could cause problems for the user, especially if the former owner performed some less than honest actions before leaving.
Once again, strict record-keeping is an important part of a User and Group Management Strategy. In addition, you will need to perform a group manager identification process before you can proceed with the creation of any groups within your parallel network.
Best Practice: Managing Global Groups
Global groups are the groups that are used to contain users. In most enterprise networks, the Global groups you create will fall into four categories:
• IT user roles This type of role identifies a person's IT user role within the organization. IT user roles include a variety of different activities. Examples of these group types include the following:
• Information worker
• Management and management support
• End-user developer
• Web/intranet editor
• System developer
• Systems or security administrator
• Systems and user support
These IT user roles allow you to create horizontal user groupings that span your organization and allow you to manage people who perform similar tasks no matter where they are located both within the organization and within your AD structure. These roles are related to the computer vocation roles identified in Chapter 5. Try to limit these roles to less than 20.
• Line-of-business groups In most cases, you will also need to be able to manage users vertically. For example, if the Finance department wants to contact all of 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 email messages, thus a group will still be required. In addition, many departments will 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 that is required. This means you follow the hierarchical structure of the company to one level below departments. Thus in the Finance department you would find the Finance group, then Payables, Payroll, Purchasing, and so on. You may require a more detailed division for your groups within the IT department itself.
• Project-based groups Organizations are constantly running projects. Each project is made of different people from different sections of the organization. Projects are volatile and last only for definite periods of time. Thus, unlike the two previous group types, project-based groups are not permanent. Because of this, this group type is the one that gives you the most work. It is also because of this that this group type may involve the creation of other group scopes, not for the inclusion of users, but rather for the assignation of permissions to project resources. Once again, try to keep a tight rein on the number of groups you create.
• Special administrative groups The last Global group type is the special administrative group type. Like the first two group types, this group type is more stable than project groups. It is required to support the application of special administrative rights to groups of users. For example, if you need to either 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 that the key to a successful group management strategy is documentation, both within and without the directory. Document your groups within the directory using the strategies outlined previously. Document your groups outside of the directory through external databases and other documentation methods. Once again, the tools on the companion Web site will be useful to support this task.
Was this article helpful?