Without a clear, organized plan, its easy for the groups to blend together and overlap each other, resulting in chaos.
In Part 1 (
Implementing Windows 2000 Groups
), I introduced you to the four types of groups that are available in Windows 2000: local groups, domain local groups, global groups, and universal groups. In that article, I explained the purposes and appropriate uses for each type of group. In this article, I will continue the discussion by providing you with some methods for planning how to implement a group structure in your organization.
As you can imagine, it's important to have an organizational plan to follow before you begin implementing groups. Without a clear, organized plan, it's easy for the groups to blend together and overlap each other, resulting in chaos. The methods I'll be discussing in this article are just some ideas that work well. If you have an organizational method that works better for you, feel free to use it as long as it conforms to the purposes and limitations of the various types of groups.
In Part 1, I briefly touched on the concept of group nesting. As you may recall, group nesting is the practice of placing one group inside another. If used properly, group nesting can be a very effective technique for organizing your network. Not only does group nesting simplify network management, it can also reduce the amount of network traffic that flows between domains. Most of the techniques I'll be using depend greatly on group nesting. Although group nesting is designed to reduce network traffic and management burden, it can quickly get out of hand if applied recklessly--therefore, here are a few tips for effective group nesting:
- Minimize the number of levels you're nesting together. It's easy to get carried away and nest 10 or 15 groups. However, doing so makes it difficult to track down problems that may occur. The more levels of nesting you use, the better your chances of having some undesired permissions (or denials) applied to users by accident. I recommend using no more than one or two levels of nesting unless absolutely necessary.
- When setting up nested groups, use the types of groups that are best suited to the job. As I explained in Part 1, each type of group has a targeted purpose. By using the appropriate types of groups, you'll be able to get away with nesting fewer levels. You'll see some examples later.
- Document everything. It's not so important to document the group memberships of individual users, because these memberships change on a daily basis. However, it's important to document the function of each group. Doing so will help you to spot potentially overlapping permissions. If you're working with large numbers of nested groups, drawing a diagram of what each group controls and which groups are linked is a very effective technique.
|Group Functions Reminder |
It's important to understand the intended role of each group type. Here's a reminder of the purpose of each type of group:
- Global groups--In native mode, global groups can contain users and other global groups. These users and groups must belong to the same domain as the global group. In mixed mode, global groups can contain users from within the domain.
- Domain local groups--In native mode, domain local groups can contain user accounts, universal groups, and global groups from any domain in the organization. They can also contain other domain local groups from the same domain the group resides in. In mixed mode, domain local groups can contain user accounts and global groups from any domain in the organization.
- Universal groups--Universal groups can contain user accounts and other universal and global groups from any domain in the organization. Universal groups exist only in native mode.
Planning Global Groups and Domain Local Groups
Let's look at some techniques for implementing global groups and domain local groups. I recommend assigning users with similar jobs to global groups. For example, within the IT department, you might have a Programmers group and a Network Support group.
The next step is to create a domain local group for each shared resource or group of shared resources. For example, if you have a C++ library on the network, you might create a domain local group for it called C++. Likewise, if you have a shared printer, you might create a domain local group called Laser Printer.
Once you've created the domain local groups for the various resources and assigned them the necessary permissions, you can begin adding the global groups that you created earlier to the domain local groups, based on who needs access to what. For example, you might add the Programmers global group to the C++ domain local group. You might also add the Programmers global group and the Network Support global group to the Laser Printer domain local group so that both groups can print to the printer.
Obviously, there are some other ways to get the job done. You might wonder why you shouldn't just add the user accounts directly to the domain local groups instead of nesting two types of groups. As you may recall from Part 1, domain local groups can accept members from any domain, but they can only regulate resources in the current domain. Adding users directly to a domain local group reduces your flexibility to work with resources in other domains.
Planning Universal Groups
Universal groups are generally used on bigger networks. Unlike domain local groups, universal groups can control permissions for any resource regardless of which domain it belongs to. In some organizations, the programming staff is placed into a universal group. When the programmers develop an application, they usually have to make sure the application's printed output is printed correctly on the various types of printers within the organization. One way of granting the appropriate access is to place all the programmers into a universal group and assign the universal group access to all the printers in the organization.
Universal groups are powerful; but, I recommend that you use them sparingly, because of the side effects caused by making modifications to the groups' permissions or resources. Remember that universal groups can have members and resources from any domain in the organization. In large organizations, a universal group may be linked to dozens of domains either through membership, resources, or both. Suppose you have such a group and you decide to make a minor change to it, such as adding a member. Obviously, the change will be applied to a domain controller in your domain. However, this event triggers a chain reaction. The updated domain controller must then replicate the change to the other domain controllers within the domain. Once the domain has been updated, the change is eventually replicated to every domain controller in every domain the universal group affects (not just the domains affected by the change). The replication process causes lot of network traffic. Therefore, if you do decide to implement a universal group, try to design it in such a way that it will usually remain static.
Perhaps the best way of avoiding the whole replication from hell situation is to use the universal group as if it were a domain local group. The big limitation with domain local groups is that they can only be assigned to resources in the local domain. If you need to regulate resources in multiple domains, go ahead and create a universal group, and assign the permissions to the resources that you need.
Once you've assigned all the necessary resource permissions, add global groups to the universal group instead of adding individual members. You're much less likely to change the global groups that are members of a universal group than you would be to change individual group members. Instead, make the individual users members of the global groups. Because global groups are domain specific, making changes to them doesn't cause massive replication traffic like making changes directly to a universal group.
Right now, your head may be spinning from all the different types of group nesting techniques I've covered. To make the discussion easier to follow, check out the chart in Figure 1; it outlines the concepts I've described in this article. In Part 3, I'll continue the discussion of group security by discussing the groups that are built in to Windows 2000. //
Figure 1: This chart outlines the nesting concepts I've covered in this article.
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the Director of Information Systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.