Planning Your Group Structure Implementation - Page 2

By Brien M. Posey | Posted Nov 9, 2000
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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.

CrossLinks

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.

Summing Up

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.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter