Managing OUs, Users, and Groups in Active Directory

This chapter is from the book

Inside Active Directory: A System Administrator's Guide

Learn More Buy

This chapter is from the book

This chapter is from the book 

Inside Active Directory: A System Administrator's Guide

Learn More Buy

Administering Groups

Managing users, contacts, and computer objects is usually much more effective when you treat them in groups than when you treat them individually. Whether you need to send e-mail or assign permissions for a printer, you most often want the target to be several users instead of just one. When you need the same group again, the fact that you already have it created will save you work. Of course, there is no laborsaving benefit if you create a group and then use it only once.

Groups are extremely handy and you really cannot manage a network without them. However, you use them mainly for assigning permissions and group policies. Specifically, you cannot use groups for the following purposes:

• Setting properties of several users, contacts, or computer objects, or applying properties for them

• Moving or deleting several users, contacts, or computer objects

In addition to administrators, end users can use Active Directory groups, usually as distribution lists. Table 3.17 describes in more detail the purposes for which you can use groups.

Group Types

You can create two types of groups in Active Directory, security groups and distribution groups. Both types can have users, contacts, and computer objects as members.

Table 3.17 illustrates that security groups have two natures, but distribution groups have only one. Thus, distribution groups have a subset of security group features.

As Table 3.17 indicates, a security group has all the features of a distribution group, and it can also be used for assigning permissions. This leads to the following question: Why do we use distribution groups at all, if they are less capable? The reason is that they are a little "cheaper" than security groups in terms of logon process.

TABLE 3.17 The Nature of Security and Distribution Groups

When a user logs on to the network or accesses the resources of a server for the first time, Windows 2000 builds an access token for that user. An access token is a list in RAM that contains the user's identity and the groups that the user belongs to. But it doesn't contain any distribution groups. Because distribution groups are not needed when determining access, they are not needed in the access tokens. This, in turn, leads to a somewhat faster logon process and a smaller access token in memory. Of course, you probably won't notice the difference in a small network.

On the other hand, as long as you don't have any directory-enabled applications, you cannot use distribution groups, even though you can create them. Remember that Windows 2000 doesn't use them. This means that it's quite possible that you need to create only security groups, even though they are a little more "expensive."

Figure 3.21 summarizes the features of the two group types.

Figure 3.21 The solid lines in this figure represent the security nature of groups. All lines except the thin solid line in the lower-left corner represent the application nature of groups.

Group Scopes

In addition to the two group types (security and distribution), groups are divided into three scopes: global groups, universal groups, and domain local groups. The group scope indicates if the group can accept members from other domains and if it can be used in other domains.

Group scopes are not very important if you have only one domain. In that case, you can do just fine with only universal groups, unless you anticipate having several domains at some later time.

Group scopes and nesting behave differently depending on whether your domain is in mixed mode or native mode. We will first explain the mixed-mode case. Even if you have already changed your domain to native mode and/or plan to use only native mode, you should read the section about mixed mode. In the next section we explain many principles of how to use groups in administration, regardless of the mode.

Group Scopes in Mixed Mode

Distribution groups in mixed mode work just like distribution groups in native mode. Consequently, we'll discuss distribution groups in the next section, which is about native mode.

Security groups in mixed mode work like the groups in Windows NT. You can have global and domain local security groups, but you can't have universal security groups.

You cannot freely nest security groups in mixed mode, but you can put global groups as members into domain local groups, as Figure 3.22 illustrates.

In the one-domain case in Figure 3.22, you can draw an arrow from any circle to any other, as long as you move downward. In the two-domain case, only the two upper circles are visible in the other domain, and only the two lower circles accept arrows from the other domain.

Figure 3.22 In mixed mode you can put users and computer objects in global groups, put global groups in domain local groups, and then give permissions to domain local groups. This preferred arrangement is indicated in the image by thick lines. You can also use the shortcuts indicated by the thin lines.

Remember that normal trust relationships in Active Directory are bidirectional. In the case of two domains, domain A trusts domain B and vice versa. Consequently, a domain A global group can be a member of a domain B domain local group, and a domain B global group can be a member of a domain A domain local group. In other words, if you looked at Figure 3.22 in a mirror, you would see a similar figure.

Because Figure 3.22 has quite a few arrows, to simplify the two-domain case, Figure 3.23 shows only the preferred (thick) arrows.

Figure 3.23 Global groups are usually associated with people (and computer objects). Domain local groups are resource oriented. The dotted boxes symbolize this division.

The thin lines (shortcuts) are less desirable for the following reasons:

• By giving permissions to one group instead of 200 users, you get dramatically shorter permission lists. This saves disk space, speeds up permission evaluation, and is easier to manage. For example, when your organization hires a new employee, she will get all the needed permissions when you add her to a few groups. The worse alternative would be to go through all server folders and add permissions to this new user.

• You should use global groups to group users (and computer objects). These groups are also a level of isolation. If the user list changes, the groups stay the same, and therefore hide the changes from the lower levels. This is especially valuable in a multidomain situation. If one domain gets a new user, the administrators in other domains don't have to do anything, because they already have the appropriate global groups as members in the appropriate domain local groups.

• You should use domain local groups for resource-oriented purposes. You often create a domain local group either for one resource or for a certain type of resource, such as all color printers. This way, if a new group of users needs access to all the color printers, you can just make this group a member of the rColorPrintersPrint domain local group, instead of giving permissions for 17 color printers individually.

Example of Group Usage

We present in this section a basic example of group usage. We want to limit the number of people who can print on the color printers in our domain, so we perform the following steps.

1. When we deployed Active Directory, we established certain global groups to group the users in our domain. We put the users in groups based on the organizational structure (oMarketing and oFinance), as well as functional categories (fAssistants and fManagers). Note that we cannot use OUs for anything here.

2. Now we create a new local group, rColorPrintersPrint, and give that group permission to print to each color printer. We have three color printers and we have to assign the Print permission for each printer individually.

3. As the final step, we assign appropriate global groups as members of the rColorPrintersPrint group. We want everyone in the marketing department and all managers to be able to print in color.

Figure 3.24 illustrates the result.

If you have only one domain and you feel that you don't need two levels of groups, you may skip either level. Either you can make users (and computer objects) members of domain local groups, or you can give permissions directly to global groups.

The domain local group in Figure 3.24 may seem unnecessary. However, imagine that you have 17 color printers and, along with marketing personnel and managers, you want to allow assistants to print to them. With the domain local group you can do this quickly: You only need to put fAssistants as a member in rColor PrintersPrint. Without the domain local group, you would need to open the properties dialog box of 17 printers in quite a few servers and assign permissions to fAssistants individually in each dialog box.

Figure 3.24 We have grouped our users into global groups, so we don't need to handle individual users. We give the actual Print permission to a domain local group and then assign appropriate global groups as members of this domain local group.

Group Scopes in Native Mode

In native mode you can have any of the three group scopes in either of the two group types—that is, there are six possible combinations. Unlike in mixed mode, in native mode you can have universal security groups.

Security groups and distribution groups work the same way in native mode. Therefore, we don't need to make a distinction between them and we don't discuss them separately here.

In mixed mode, global groups are the upper level and domain local groups are the lower level. In native mode, universal groups are a third level between the two earlier levels. A group from a higher level can be a member in a group from a lower level, as Figure 3.25 illustrates.

Figure 3.25 In native mode you have three levels of groups. Any upper-level object can be a member of any lower-level object. This figure illustrates the situation in one domain.

Deciding on how to use all these groups in native mode is more complicated than in mixed mode. We delve into this discussion in the "Planning Groups" section later in the chapter. We'll just mention the three basic strategies here:

• Forget universal groups and use only global and domain local groups, as described in the preceding section about mixed mode.

• Use only universal groups.

• Use all three levels (and pray that you know what is going on in Active Directory). If you have several domains and sites, you will probably need all three levels.

Figure 3.26 introduces a second domain. It illustrates that global groups cannot accept members from other domains (except contacts), and domain local groups cannot be used in other domains, but universal groups don't have either of these restrictions.

Figure 3.26 When crossing domain boundaries, global groups cannot accept members from other domains, and domain local groups cannot be used in other domains. Universal groups, however, have no such restrictions.

If one of the domains in Figure 3.26 were in mixed mode and the other were in native mode, the image would still be accurate. Obviously, one of the domains couldn't have universal security groups, but after having removed that, all the remaining arrows would be valid. For example, if domain A were in mixed mode and domain B were in native mode, the domain local groups in domain A would accept both global and universal groups as members from domain B.

The figures so far have shown only one group of each scope in each domain. In reality, you will have many groups of each scope. In native mode you can freely nest groups of the same scope. Global group A can be a member of global group B, which is a member of global group C, which is a member of global group D, and so on. In other words, any group can be a member of any other group of the same scope in the same domain.

Building on Figure 3.26, Figure 3.27 shows five groups of each scope in each domain.

Figure 3.27 Within each scope in each domain, any group can be a member of any other group. From one scope or domain to another, groups that can be a member of other groups are indicated with an arrow.

Built-in Local Groups

The last aspect of group scopes concerns the built-in local security groups (Administrators, Account Operators, and so on) that reside in the Builtin container. Technically, they belong to a different "domain"—the Built-in domain—therefore, you cannot nest domain local groups with built-in local security groups or vice versa. Figure 3.28 illustrates this concept.

Figure 3.28 Built-in local security groups belong technically to a different "domain." Therefore, you cannot nest them with domain local groups.

Managing Groups

Now you are ready to create and manage groups. Before you implement the groups in your production environment, you should first read the "Planning Groups" section of this chapter.

Managing groups includes the following tasks:

• Creating groups of different types and scopes
• Changing the type or scope of a group
• Managing group memberships
• Setting the primary group of a user
• Setting group properties
• Moving, renaming, and deleting groups
• Sending e-mail to groups

When you create and manage groups, we suggest that you visualize your groups in the way that we have presented groups in the figures in this book. Having a clear visual image of them in your head, or even on paper, will help. The user interface of the Users and Computers snap-in doesn't indicate graphically that you should put users in global groups, global groups (perhaps) in universal groups, and so on.

Creating Groups

You create groups with the Users and Computers snap-in just like you create any other object. Right-click the target OU and select New, Group. Figure 3.29 is a screen shot of the dialog box that appears. Because you cannot assign permissions to an OU, the first group you create is probably a global security group with the same name as the OU. When you add each user of the OU to this group, you can give him or her permissions with the help of this group.

Figure 3.29 When you create a group, the first dialog box that appears calls for naming the group and assigning its scope and type. The first group is likely to have the same name as the OU.

Table 3.18 describes the two names shown in Figure 3.29.

TABLE 3.18 Name Properties of a Group Object

Many of the dialog boxes in the Users and Computers snap-in give no hint of the scope or type of existing groups. Therefore, you might consider adding your own hint—for example, add "gs" to the name, with "g" standing for "global" and "s" standing for "security" group. With domain local groups you could use "l" instead of "d" to not confuse them with distribution groups.

You could also use letters to indicate whether the group was created by organization, by functionality, by resource, or by some other criteria. Table 3.19 gives some suggestions on how to use these symbol letters.

TABLE 3.19 Symbol Letters for Group Names

In addition to making names more descriptive, these symbols sort similar groups sequentially when the user interface is using an alphabetical list.

Table 3.19 presents examples of letters that indicate scope and type, such as "gs," and letters that indicate logical grouping, such as "o." Of course, you can use both types, but be aware that confusion can arise if you use too many identifiers like these.

Changing Group Type or Scope

Mixed mode doesn't enable you to change group type or scope. Native mode enables these changes, with two restrictions (see Figure 3.30).

• If the new type or scope would lead to an illegal situation in terms of memberships, the change is obviously forbidden. For example, if your domain local group has other domain local groups as members, you cannot change it to a universal group. Universal groups cannot have domain local groups as members.

• You cannot change a domain local group to a global group or vice versa, except via a universal group.

Figure 3.30 You can change a group scope to and from a universal group, but you can't change scope directly from a domain local group to a global group or vice versa.

Managing Group Memberships

Each user, contact, computer, and group is a "member" of only one OU. At the same time, each can be a member of several groups, because a group membership is just a group property; it is not part of the tree structure.

The Users and Computers snap-in allows you to manage group membership in three ways:

• The Members tab of the group
• The Member Of tab of the (incoming) member
• The "Add members to a group" function

One of the Active Directory design goals was drag-and-drop administration. In the first version of Windows 2000, however, you cannot drag objects over groups to become members of them.

The Members Tab of the Group

The first way to manage groups is through the Members tab. When you right-click a group, select Properties, and then click the Members tab, you'll see a list of the members of the group, as Figure 3.31 shows.

As you would guess, you remove members by selecting them and clicking the Remove button.

Figure 3.31 The gsSales group currently has users, contacts, computers, and other groups as members.

To add members to a list, click Add. Another dialog box opens where you can select objects to be added as members. To select members for a group, in the "Look in" field choose the domain (or Entire Directory), select objects from the list, and click Add. The selected objects then appear in the lower box and you click OK (see Figure 3.32).

Figure 3.32 To select members for a group, first choose the domain (or Entire Directory) in the "Look in" field, select the members from the list, click Add to copy the selected objects to the lower list, and then click OK.

Instead of selecting objects from the list, you can type their names in the lower list. Then you can check whether they are valid with the Check Names button. If you want to type several names, you must separate them with semicolons. If more than one object matches the name you typed, clicking Check Names brings up dialog box in Figure 3.33.

Figure 3.33 If you type a name that matches several objects, you are prompted to select the name you intended.

The Member Of Tab of the Incoming Member

User, contact, computer, and group objects have a Member Of tab, which shows the groups that the object belongs to. If you have several domains in the forest, however, the tab shows just universal groups from other domains.

The Members Of tab and consequent dialog boxes work in the same way as the Members tab and consequent dialog boxes.

Add Members to a Group Function

The context menu of each user and contact (accessed with a right-click) has an "Add members to a group" option. When you select this menu item, you can choose the group in which to place the selected object.

The "Add members to a group" option is a menu item for each OU, also. In this case, you can make all users and contacts in the OU members of the group. If the OU has child OUs, you can choose for each one whether to include users and contacts in them as well.

Setting a User's Primary Group

Each user and computer object's Member Of tab includes a setting for a primary group. You probably won't need this setting, because it is used only by the POSIX subsystem (i.e., when running a kind of UNIX application in Windows 2000) or by Apple Macintosh workstations.

The default primary group of a user is Domain Users and the default primary group of a computer is Domain Computers. If needed, you can change this setting to some other global or universal security group.

You cannot remove an object from its primary group. Therefore, if you want to move a user out of Domain Users, you first must change that user's primary group to something else.

Setting Group Properties

Behind the scenes a group object may, by default, have 107 properties. However, many of them are not needed, so the user interface displays only a few of them, as shown in Figure 3.34.

Figure 3.34 There are not many properties that you can set for a group object using the user interface.

Table 3.20 lists the properties of group objects that are visible in the Users and Computers snap-in other than group type, scope, and members, which we discussed in the previous sections. The settings are mostly self-explanatory. Note that Windows 2000 also provides context-sensitive help for each of the settings.

TABLE 3.20 Properties of a Group Object

Moving Groups

You move groups between OUs just like you move other objects. When moving them within a domain, you right-click the group, select Move, choose the destination, and click OK. To move groups between domains in your forest, you use the Support Tools command-line tool MoveTree. It is discussed in Chapter 6.

You move several sibling objects at once by selecting them in the right-hand pane of the snap-in and using the Shift and/or Ctrl key.

When you move groups

• Permissions that are assigned for the object being moved move with the object.

• Permissions that are inherited from above do not move with the object being moved. Instead, the object inherits new permissions in its new location.

Renaming Groups

You rename a group either by right-clicking it and selecting Rename or by selecting the group and pressing F2. After you type the new name, press Enter. Because groups also have a pre–Windows 2000 name, a dialog box appears that gives you a chance to change that name, too.

Deleting Groups

You delete an object by right-clicking it and selecting Delete or by selecting the object and pressing the Delete key. Because there is no Undo, as a safety mechanism, you must confirm that you want to delete the object.

Like a user, a group is a security principal. Therefore, if you delete and then recreate it, the new object doesn't have the memberships or permissions of the old one.

Sending E-mail to Groups

If the group has an e-mail address defined, you can send it e-mail with the "Send mail" operation in the context menu. Naturally, you need an e-mail application for this feature to work.

Planning Groups

Now you know group mechanics and properties, so you can use this knowledge to decide what the best way is to use groups effectively for a specific network in terms of manageability, administrative burden, and cost to network efficiency.

Planning groups involves deciding on group names, types, and scopes.

• It often pays to use letters in group names that indicate the kind of group it is, as explained earlier in this chapter.

• As explained earlier, because of access tokens, you should use distribution groups when you don't need the security feature but intend just to use the group with some directory-enabled application.

• This section concentrates on group scopes and describes three strategies for using them.

Before we discuss the three strategies, we need to study universal groups a little more.

Universal Groups Revisited

Recall that universal groups don't have the limitations of global or domain local groups. This prompts the following question: Why not use only the most feasible (i.e., universal) groups? Actually, Microsoft originally planned Active Directory to have only universal groups, not global or domain local groups. But the universal groups introduce extra cost, so Microsoft brought along the other two scopes.

Universal groups are more expensive in two ways. The first is related to the global catalog and the second is related to access tokens. Table 3.21 explains both.

The outcome of the rightmost column in Table 3.21 is that if you have only one domain, neither cost in the table is an issue, so you can use universal groups with confidence.

TABLE 3.21 The Extra Costs Related to Universal Groups

The reason to have universal group members in the global catalog is to provide an efficient means to effectively implement groups in a WAN environment with multiple sites. The global catalog takes care that the membership information is present on all sites (provided each site has a global catalog server). Therefore, checking a user's membership (needed to determine his access to resources) doesn't require crossing WAN links to other sites.

To summarize, we can make two claims that may sound contradictory at first:

• Universal groups are suitable for small networks.

• Universal groups are suitable for large networks.

The rationale behind the two claims comes from the three benefits of universal groups.

• For small networks: Cost is not an issue, and universal groups are easy to learn because there is only one scope with free nesting.

• For large networks: Universal groups provide an effective way to create groups with members from multiple sites.

• For large networks: Only universal groups have the scope to take members from different domains and to be assigned permissions for resources in different domains (see Figure 3.35).

Figure 3.35 If you need a group that can have members from different domains and that can be given permissions for resources in different domains, your only choice is a universal group.

The first benefit (for small networks) means that you would use only universal groups. The other two benefits (for large networks) means that you would use universal groups occasionally in addition to global and domain local groups.

Three Group Strategies

There are three basic approaches to organizing groups according to scope, as Figure 3.36 illustrates.

Figure 3.36 Depending on your network's size and needs, you can choose one of three group scope use strategies.

• Use only global and domain local groups. If you feel comfortable with the two levels of groups that global and domain local groups provide (most likely from earlier Windows NT experience), you could use this as your group strategy. You either have just one domain or maybe a few of them.

• Use only universal groups. If you have only one domain and you don't want to learn and think about different group scopes or levels, you will do fine with using just universal groups. You can use one level of groups between users and resources, without group nesting. Or you can put some groups in other groups to have a little nesting. Whether or not you develop logical levels for your groups is your choice. Of course, there are always some predefined global and local groups.

• Use all three scopes. If you have multiple domains (and perhaps sites), you probably need all three group scopes. You'll mostly use global and domain local groups because they don't have the extra "cost." In this strategy, you use universal groups only when you need a group with members from different domains (perhaps in different sites) and when you want to assign permissions for resources in different domains.

We have a few final comments about group usage before we move on to the next section.

• Don't get carried away with group nesting. If you have more than three levels, you might lose track of your group hierarchy. Too much nesting could easily confuse, rather than simplify, network administration.

• You might want to create a group containing only one person. Active Directory doesn't have a role object class like Novell NDS has, but you could use groups in this sense. Usually one person at a time holds a role, so the group has only one member. For example, if some user is taking care of backups this month, you could put her in a group and give that group the appropriate permissions. When someone else takes over the role, you change the group membership by removing the first user and adding the new user.

• You may want to offer your security groups for users to be used in e-mail, but the names have symbol letters and other conventions that might trouble your users. In this case, you can create a corresponding distribution group with a user-friendly name and make the distribution group a member of the security group.