Home > Articles > Operating Systems, Server > Microsoft Servers

This chapter is from the book

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.


Even though labeled "application nature," an application could use the distribution feature also for some security use. For example, you could have an application that controls the doors of your company. The application could open a certain door for a user if he is a member of a certain distribution group.


Security groups are the traditional groups that existed in Windows NT. Distribution groups are new.

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





Security nature



Assign permissions, and possibly audit settings, for folders, files, and Active Directory objects

Group is a security



Assign group policies (not directly, but by

principal, which



assigning permissions for a certain Group Policy

Windows 2000 uses to determine permissions.



only to some group) Other miscellaneous uses, such as check the group membership in a logon script and then apply some commands, in case the user was in that group

Application nature



Send e-mail (i.e., the group operates as a distribution list)

Group is available to directory-enabled applications. Windows 2000 doesn't use it but any application may use it.



When using a directory-enabled application, use the group for whatever purpose the application needs

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.


Access tokens are discussed in more detail in Chapter 4.

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.


A contact is never able to log on, so it never gets an access token, and it cannot access resources. Therefore, it is not part of the security nature of groups, even though it can be a member of a security group.

Figure 3.21 shows groups as members of other groups. Depending on the domain mode (mixed/native) and group scopes (discussed in the next section), not all groups can be members of all other 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.


Contact objects don't quite follow the containment rules that we will present from this point on. A global group can have user and computer object members only from its own domain, but it can have contact object members also from other domains.

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.


We don't include contact objects in the figures from now on because we are concentrating on the security nature of the groups.

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.


The first r in the rColorPrintersPrint domain local group name indicates that it is a resource-oriented group. Print indicates that this group has the print permission for the corresponding printers. You can use these kinds of naming conventions at will.

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 a workstation or member server, instead of a domain controller, handles one of the color printers, the domain local group cannot be used while we are still in mixed mode. Once we change to native mode, we can start using domain local groups in workstations and member servers.

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.


Figure 3.26, Figure 3.27, and Figure 3.28 are more complex than earlier images. To be as clear as possible, we don't show users and computer objects on the top or resources on the bottom in those three figures. You can still imagine them to be there.

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.


Because there are three possible strategies for using groups in native mode, Figure 3.25 does not indicate (with thick lines) a preferred path.

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.


As you may remember from the mixed-mode section, the arrows between domains should be symmetrical. To keep Figure 3.26 uncluttered, we do not show the arrows from domain A to domain B.

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.


In Figure 3.27, the arrow from the global groups in domain A to the universal groups in domain A symbolizes that any of the upper five groups can be a member of any of the lower five groups. An actual representation would have 25 arrows, but we use just one. These 25 arrows would be needed 14 times, between each scope of groups in each domain. To give you a clear image, we use only 10 arrows instead of 350.

Again, in Figure 3.27, arrows from domain A to domain B were left out to make the image clear.

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



Maximum Length




Group name

name (RDN) and

cn (Common-




Within OU

This becomes the object

common name in the


Group name (pre–Windows 2000)




Within domain

This name appears on non–Active Directory computers and software, such as the old User Manager. Despite its label, this name can be used throughout Windows 2000.


Distribution groups are created for directory-enabled applications. It is unlikely that those applications use the pre–Windows 2000 name. However, you must define it for every distribution group.

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






Global security groups



Universal security groups



Domain local security groups. The first group has



permissions to use SAP software and the second group has permissions to print in color.



Groups created according to the organizational structure



(which don't match OUs).



Groups created to match OUs



Groups created according to function (for example,



salesmen from all OUs)



Groups created for resources. Because these are usually



domain local groups, this example has the same group names as the "ls" example.

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.


The Users and Computers snap-in actually allows you to change a global group to universal, even if the group-to-be-changed is a member of another global group. Because the result is illegal, however, the corresponding membership is not effective.

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.


If you delegate group management to assistant administrators, you should advise them to modify group memberships only on one domain controller (perhaps the PDC emulator). All members of a group are stored in one multivalued property. If that member list is modified on two domain controllers simultaneously (within replication latency), one of the two changes will be lost.

You could give users the permission to "Add/Remove self as member" of some group. For the reason given in the previous warning, some changes could be lost, and the risk would be quite great if all users could modify membership themselves.


Because all members of a group are stored in one multivalued property, there is a limit of 5,000 members in one group.

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.


You can select several members simultaneously by holding down the Shift and/or Ctrl key.

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.


The primary group of a user is not stored in the members property of the group, but rather in the primaryGroupID property of the user. Consequently, the 5,000-member maximum doesn't apply to primary groups, which means that you could have 100,000 users (or more) in your domain and they could all be members of Domain Users.

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







General Tab



Text (1024)




Group name (pre–Windows 2000)


Text (256)



This name appears on non–Active Directory com-puters and software, such as the old User Manager. Despite its label, this name can be used throughout Windows 2000.



Text (256)






Text (1024)




Managed By Tab

Managed By


DN* (you select a user or contact from list)



The user or contact you select doesn't get permission for the group. This setting is purely informational. The other fields on the tab are the manager's properties.

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



Is an Issue

Global catalog

All membership information of universal groups is replicated to the global catalog. This means that every time the members change, this information has to be replicated to all sites of the enterprise throughout the world (provided that they all have a global catalog server). To minimize changes, have only groups as members of universal groups. This way, changes in membership don't occur as often as when users are members.

If you have both multiple domains and multiple sites

Access tokens

Global and domain local groups come only from the applicable domain into the user's access tokens. Universal groups, however, come to the user's access tokens from all domains of the enterprise forest. Thus, using universal groups leads to larger access tokens (consuming some memory) and to slower logon times.

If you have multiple domains and a fairly large number of 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.


If you test universal groups, you may run into the following "problem": You create a test universal group on a domain controller that is not a global catalog server. Then you test the new group and find out that it doesn't work (yet). The reason is that, because the universal group membership is read from a global catalog server, it doesn't work until the group and the membership information have been replicated to the global catalog server, where your domain controller reads this information. You may even be sitting at a domain controller that contains this information, but still it must be read from elsewhere.

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.


If you removed the universal group from Figure 3.35, you could achieve the same networking result. It would be very cumbersome to do so, however. You would need 9 (3 3 3) direct memberships from the global groups to the domain local groups. Or, with 17 domains, you would need 289 (17 3 17) direct memberships.

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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020