Implementing Windows 2000 Groups
I've written quite a few articles on the subject of Windows 2000 security. Most of these articles focus on advanced topics, such as symmetric multikey encryption, or digital certificates. However, some of the lower-end security mechanisms can be just as important. For example, in this article, I'll be discussing group-related security. Although a group is nothing more than a collection of users or other resources, groups are one of the most important security structures in Windows 2000. Implementing groups incorrectly (or not at all) can lead to all sorts of problems, like conflicting permissions or a security scheme that's impossible to manage.
Why Use Groups?
If a group is simply a collection of users, you may wonder what the big deal is about using them. After all, nothing in Windows 2000 stops you from assigning permissions to individual users. However, it's much easier to work with groups than with individual user accounts. For example, suppose you make a new application available to the users. Would you rather individually assign permissions to 1000 users, or assign the permissions to a single group?
Convenience in assigning permissions is not the only reason to use groups. In fact, groups should be the backbone of your security infrastructure. Microsoft recommends that you never assign permissions of any kind to an individual, but rather assigning all permissions on a group basis. Unfortunately, without a good understanding of the different types of groups and their specific functions, it's easy to make a mess out of your security architecture. In this article, I'll discuss the various types of Windows 2000 groups. Once you're familiar with the various types of groups, I'll continue the discussion in Part 2 of this series by discussing how the various types of groups interact with each other.
Distribution Groups vs. Security Groups
If you have a background in Windows NT, then you know that NT contains only one native type of group. However, the Windows 2000 Active Directory supports two types of groups: distribution groups and security groups. Distribution groups aren't related to security issues; they're only used for grouping users (or other resources) for non-security-related purposes. For example, if you often need to send an e-mail message to all the managers in the company, you can group the managers into a distribution group and send the e-mail message to the group rather than to individual people.
Security groups, on the other hand, are more like the groups in Windows NT. You can use a security group to assign a group of people access to an application, directory, or other resource. You can use security groups as distribution groups, but you can't use distribution groups as security groups.
Now let's look at another important issue: group scopes. A group's scope refers to how and where you can use the group to assign security permissions. Windows NT used two basic group scopes: global groups and local groups. Windows 2000 uses global and local groups, and adds two more scopes: universal groups and domain local groups.
Local groups are used to protect resources on workstations or member servers. As you may recall, workstations and member servers all maintain their own security accounts database, which functions independently from the SAM or the Active Directory. These local security accounts allow you to locally access a machine whether it's connected to a network or not.
Local groups are a way to restrict local resources from these accounts. For example, suppose you have a single PC in the office that everyone takes turns using. If only three people need access to a particular directory, you can create a local group on the PC that regulates access to that directory.
You should be aware of a few rules that apply to local groups:
- Local group membership is limited to accounts from the local machine.
- Local groups can't be part of other groups.
- You can't create local groups on domain controllers, because domain controllers don't keep a set of security accounts that function separately from the domain security accounts.
Domain Local Groups
Domain local groups function similarly to local groups, except that their use is more widespread. Domain local groups can be used to protect resources anywhere within the domain. A domain local group can contain users from any domain, but it's limited to regulating resources in the same domain in which the group exists.
Global groups function the opposite of domain local groups. Global groups can accept members only from the local domain. However, they can regulate resources located in any domain.
If you've got a big network, then you'll probably be using universal groups quite extensively. As you might have guessed, universal groups have very few restrictions. A universal group can contain members from any domain in the organization. It can also regulate resources that exist within any domain in the network. The only limitation to universal groups is that they exist only in the Active Directory's native mode. If you have any Windows NT domain controllers on your network, you can't use universal groups.
As I mentioned earlier, groups can contain other groups. This concept is known as group nesting. Group nesting is most effective on large networks but can be used on any size network.
To get an idea of why group nesting is such an effective technique, consider a company that's geographically spread out. Now, suppose that each of the branches needs its upper management to have access to certain files. The obvious solution is to create a management group and grant the group access to the necessary files. However, you can also create another manager group at the corporate headquarters and assign all the management groups created at the other offices as members of the group. Now, it's easy for the main office to make files available or to quickly send messages to all the managers in the entire organization.
This technique is effective because ultimately, the individual offices still maintain control of who is a member of the management group. If a new employee needs access, he or she can be assigned the access from a local level rather than having to wait for days or weeks for someone at the corporate headquarters to verify the information and assign the permissions. Likewise, if someone is fired at the local level, access can be revoked immediately.
Now that you're familiar with the various types of Windows 2000 groups and their uses and limitations, it's time to get started with designing a group-based security infrastructure. In Part 2 of this series (
Conclusionprevious ), I'll discuss group nesting in more detail, focusing on what types of groups can and can't be nested together. I'll also discuss some recommended practices you can use to implement effective group security. I'll conclude the series with a discussion of Windows 2000's built-in security groups and how to use them effectively. //
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.