This chapter is from the book
This chapter is from the book
This chapter is from the book
Administering Groups
Managing users, inetOrgPersons, 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, inetOrgPersons, contacts, or computer objects, or applying properties for them
-
Moving or deleting several users, inetOrgPersons, 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.
Table 3.17. The Nature of Security and Distribution Groups
|
Nature |
Security |
Distribution |
Purpose |
|---|---|---|---|
|
Security nature Group is a security principal, which Windows uses to determine permissions. |
X |
Assign permissions, and possibly audit settings, for folders, files, and Active Directory objects. |
|
|
Assign group policies (not directly, but by assigning permissions for a certain Group Policy only to some group). |
|||
|
Other miscellaneous use, 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 Group is available to directory-enabled applications. Windows doesn't use it, but any application may use it. |
X |
X |
Send e-mail (i.e., the group operates as a distribution list). |
|
When using a directory-enabled application, use the group for whatever purpose the application needs. |
Because inetOrgPerson objects behave identically to user objects, each time we discuss users in this "Administering Groups" section, that discussion applies also to inetOrgPersons. For brevity, we don't show inetOrgPersons separately.
Group Types
You can create two types of groups in Active Directory: security groups and distribution groups. Both types can have users, inetOrgPersons, contacts, and computer objects as members. In addition, AD2003 introduces new basic and query-based application groups. The Windows operating system, however, doesn't currently use them. We explained these new application groups briefly in Chapter 1.
AD2003 allows any object type to be a group member. You don't need such a feature in normal user administration, but a directory-enabled application could use it.
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. This Note is related to Table 3.17.
Security groups are the traditional groups that existed in Windows NT. Distribution groups were introduced with Active Directory.
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 the logon process.
When a user logs on to the network or accesses the resources of a server for the first time, Windows 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 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.22 summarizes the features of the two group types.
)
Figure 3.22 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.22 shows groups as members of other groups. Depending on the domain functional level 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 nesting means that groups can be members of other groups; that is, a group is inside another group. Group scopes and nesting behave differently depending on the domain functional level. Regarding group functionality, the four levels fall in two categories. The first category could be called "Windows NT compatible" (including the levels Windows 2000 mixed and Windows Server 2003 interim), and the other category could be called "pure Active Directory" (including the levels Windows 2000 native and Windows Server 2003).
We will first explain the Windows NT–compatible case. Even if you have already raised your domain functional level and/or plan to use only "pure Active Directory," you should read the section about mixed mode. In this section we explain many principles of how to use groups in administration, regardless of the domain functional level.
Group Scopes in Windows NT–Compatible Functional Levels
Distribution groups in Windows NT–compatible functional levels work just like distribution groups in pure Active Directory levels. Consequently, we'll discuss distribution groups in the next section, which is about pure Active Directory levels.
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 Windows NT–compatible functional levels 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 Windows NT–compatible functional levels, but you can put global groups as members into domain local groups, as Figure 3.23 illustrates.
)
Figure 3.23 In Windows NT–compatible domain functional levels 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.
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.23, 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.
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.23 in a mirror, you would see a similar figure.
Because Figure 3.23 has quite a few arrows, to simplify the two-domain case, Figure 3.24 shows only the preferred (thick) arrows.
)
Figure 3.24 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.
A domain local group is valid only in the local domain. You can use such a group to assign permissions for an Active Directory object, but when that object is replicated to global catalog servers that are members of other domains, your Allow or Deny permissions are not valid there. If a user subsequently queried this object using one of those "foreign" global catalog servers, she might get access you did not intend (because a Deny permission is not in effect). Therefore, Microsoft recommends that you shouldn't use domain local groups to assign permissions for Active Directory objects in a multidomain forest. Typically, the term resource you see in the figures on these pages refers to a shared folder or printer on a server, instead of an Active Directory object.
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.
-
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.
-
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.
-
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.25 illustrates the result.
)
Figure 3.25 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.
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 one of the Windows NT–compatible functional levels. Once we raise the level to one of the pure Active Directory levels, 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.25 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 rColorPrintersPrint. 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.
See also the "Efficient Group Nesting" section later in this chapter and the associated Figure 3.38.
)
Figure 3.38 You can develop a systematic group nesting approach by assigning each user to one small organizational group and to one small
geographical group. Then you assign these groups to larger groups, and those to even larger groups.
Group Scopes in Pure Active Directory Functional Levels
In the pure Active Directory functional levels, 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 the Windows NT–compatible functional levels, now you can have universal security groups.
Security groups and distribution groups now work the same way with each other. Therefore, we don't need to make a distinction between them, and we don't discuss them separately here.
In the Windows NT–compatible functional levels, global groups are the upper level and domain local groups are the lower level. In the pure Active Directory functional levels, 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.26 illustrates.
)
Figure 3.26 In the pure Active Directory functional levels, 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.27, Figure 3.28, and Figure 3.29 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.
)
Figure 3.27 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.
)
Figure 3.28 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.
)
Figure 3.29 Built-in local security groups belong technically to a different "domain." Therefore, you cannot nest them with domain local
groups.
Deciding how to use all these groups in the pure Active Directory functional levels is more complicated than in the Windows NT–compatible functional levels. 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 the Windows NT–compatible functional levels.
-
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 now three possible strategies for using groups, Figure 3.26 does not indicate (with thick lines) a preferred path.
Figure 3.27 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.
As you may remember from the Windows NT–compatible section, the arrows between domains should be symmetrical. To keep Figure 3.27 uncluttered, we do not show the arrows from domain A to domain B.
If one of the domains in Figure 3.27 were in one of the Windows NT–compatible functional levels and the other were in one of the pure Active Directory functional levels, 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 the Windows 2000 mixed functional level and domain B were in the Windows Server 2003 functional level, 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 the pure Active Directory functional levels, 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.27, Figure 3.28 shows five groups of each scope in each domain.
In Figure 3.28, 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.28, 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 Builtin domain—therefore, you cannot nest domain local groups with built-in local security groups or vice versa. Figure 3.29 illustrates this concept.
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 as you create any other object. Right-click the target OU and select New, Group. Figure 3.30 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.30 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.30.
Table 3.18. Name Properties of a Group Object
|
Property |
LDAP Name |
Maximum Length |
Required |
Unique |
Description |
|---|---|---|---|---|---|
|
Group name |
name (RDN) and cn (Common-Name) |
64 |
X |
Within OU |
This becomes the object common name in the tree. |
|
Group name (pre-Windows 2000) |
sAMAccount-Name |
256 |
X |
Within domain |
This name appears on non–Active Directory computers and soft-ware, such as the old User Manager. Despite its label, this name can be used throughout Windows 2000 and later. |
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
|
Letter(s) |
Examples |
Meaning |
|---|---|---|
|
Gs |
gsSales |
Global security groups. |
|
Us |
usSAPUsers |
Universal security groups. |
|
Ls |
lsSAPUse lsColorPrint |
Domain local security groups. The first group has permissions to use SAP software, and the second group has permissions to print in color. |
|
O |
oDirectSales oChannelSales |
Groups created according to the organizational structure (which don't match OUs). |
|
ou |
ouSales |
Groups created to match OUs. |
|
F |
fSalesmen fAssistants |
Groups created according to function (for example, salesmen from all OUs). |
|
R |
rSAPUse rColorPrint |
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
The Windows NT–compatible functional levels don't enable you to change group type or scope. Raising the functional level to either pure Active Directory alternative (Windows 2000 native or Windows Server 2003) enables these changes, with two restrictions (see Figure 3.31).
)
Figure 3.31 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.
-
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.
-
In a multidomain forest, you cannot change a universal group to a domain local group, unless you perform the change with a domain controller that is a global catalog server. Consequently, if none of the domain's domain controllers is a global catalog server, you cannot perform the change at all.
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.
A user's or computer's new group membership becomes effective in each server or workstation when the user or computer authenticates to that server or workstation the next time. This typically takes place when the user logs on or the computer is restarted, but it also takes place if the user creates a connection to a server where there was no existing connection.
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 to a group" function
You cannot drag objects over groups to become members of them.
If you have an AD2000 forest or an AD2003 forest running on the Windows 2000 functional level, you should take into account the following warning: 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 and scenarios given in the previous warning, some changes could be lost, and the risk would be quite great if all users could modify membership them -selves.
Because all members of a group are stored in one multivalued property, there is a limit of 5,000 members in one group. The limit doesn't apply in the Windows Server 2003 (or Windows Server 2003 interim) forest functional level.
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.32 shows.
)
Figure 3.32 The gsSales group currently has users, contacts, computers, and other groups as members.
As you would guess, you remove members by selecting them and clicking the Remove button.
To add members to a list, click Add. Another dialog box opens, where you can enter the objects to be added as members (see Figure 3.33). In the "From this location" field choose the domain or folder (or Entire Directory).
)
Figure 3.33 To enter new members for a group, first choose the domain or folder (or Entire Directory) in the "From this location" field
and then enter the names, using semicolons as separators. If you want, you can click Check Names before clicking OK.
After you have typed the new member names in the text box, 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 OK or Check Names brings up the dialog box in Figure 3.34.
)
Figure 3.34 If you type a name that matches several objects, you are prompted to select the name you intended.
When you added group members, Windows 2000 showed by default a list of possible members. Windows Server 2003 doesn't show this, because in a large domain it is time consuming. You can display the list, however, by clicking Advanced in the dialog box shown in Figure 3.33 and then clicking Find Now in the dialog box that opens.
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, from other domains the tab shows just universal groups.
The Members Of tab and consequent dialog boxes work in the same way as the Members tab and consequent dialog boxes.
Add to a Group Function
The context menu of each user and contact (accessed with a right-click) has an "Add to a group" option. When you select this menu item, you can choose the group in which to place the selected object or objects.
In Windows 2000, the "Add to a group" option is a menu item also for each OU. 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) 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 of the Windows 2000 forest functional level 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 132 properties (107 in AD2000). The user interface displays only a few of them, as shown in Figure 3.35.
)
Figure 3.35 There are not many properties that you can set for a group object.
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 Server 2003 also provides context-sensitive help for each of the settings.
Table 3.20. Properties of a Group Object
|
Property |
LDAP Name |
Syntax [*] |
Index |
GC |
Comments |
|---|---|---|---|---|---|
|
General Tab |
|||||
|
Description |
description |
Text (1,024) |
X |
||
|
Group name (pre-Windows 2000) |
sAMAccount-Name |
Text (256) |
X |
X |
This name appears on non–Active Directory com puters and soft ware, such as the old User Manager. Despite its label, this name can be used throughout Windows 2000 and later. |
|
|
|
Text (256) |
X |
X |
|
|
Comments |
info |
Text (1,024) |
|||
|
Managed By Tab |
|||||
|
Managed By |
managedBy |
DN [**] you select a user or contact from a 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. |
||
|
Manager can update membership list |
nTSecurity-Descriptor |
N/A |
X |
The Windows Server 2003 version of the Users and Computers snap-in contains this new check box. If you check this setting, the manager gets permission to modify the member property of the group. |
Moving Groups
You move groups between OUs just as you move other objects. When moving a group within a domain, either (a) drag it to a new location with the mouse, (b) use cut/paste with the keyboard or mouse, or (c) right-click the group, select Move, and then choose the destination from the OU tree that opens up and click OK. To move groups between domains in your forest, you use another tool, such as 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 a group by right-clicking it and selecting Delete or by selecting the group and pressing the Delete key. Because there is no Undo, as a safety mechanism, you must confirm that you want to delete the group.
Like a user, a group is a security principal. Therefore, if you delete and then re-create 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.
Table 3.21. The Extra Costs Related to Universal Groups
|
Cost |
Explanation |
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 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.
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" (only in AD2000): 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.36).
Figure 3.36 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.
)
Figure 3.36The first benefit (for small networks) means that you would use only universal groups. The other two benefits (for large networks) mean that you would use universal groups occasionally in addition to global and domain local groups.
If you removed the universal group from Figure 3.36, you could achieve the same networking result. It would be very cumbersome to do so, however. You would need 9 (3 x 3) direct memberships from the global groups to the domain local groups. Or, with 17 domains, you would need 289 (17 x 17) direct memberships.
Three Group Strategies
There are three basic approaches to organizing groups according to scope, as Figure 3.37 illustrates.
-
Use only global and domain local groups (strategy A). 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 have either just one domain or maybe a few of them.
-
Use only universal groups (strategy B). 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 (strategy C). 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.
)
Figure 3.37 Depending on your network's size and needs, you can choose one of three group scope use strategies.
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 as 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.
Efficient Group Nesting
Group nesting in pure Active Directory functional levels is relatively free. The only restrictions are—as explained earlier in this chapter—that (a) you cannot put "lower" groups as members in "upper" groups, such as putting a universal group in a global group, and (b) based on group scopes, only some memberships are allowed across domain boundaries. Consequently, you can do almost whatever you want with group nesting.
We cannot present all the various scenarios here, but we present one efficient and systematic use of nesting. It uses the following steps (illustrated in Figure 3.38).
-
We put each user in one global group that is based on the smallest (necessary) organizational unit (not to be confused with the OUs of Active Directory). We denote these groups with "o1".
-
We put each user in one global group that is based on the smallest (necessary) location unit. We denote these groups with "L1" (where uppercase is more distinguishable than lowercase).
-
We nest the smallest organization groups into larger ones, denoted with "o2", and similarly the smallest location groups into larger ones, denoted with "L2".
-
As the fourth step, we nest the o2 groups into o3 groups, and L2 groups into L3 groups.
This approach deserves the following comments:
-
You need to put each user in only a minimal number of groups (two in this case).
-
In addition to this systematic model, you may need to put users in some other groups, such as in the functional groups illustrated in Figure 3.25.
-
If you implement the scenario in a single domain, you can do with just global groups.
-
If you have several domains, either your organizational or geographical group division does not match your domain division. Consequently, some of your group memberships must cross domain boundaries, and consequently, some of the o2, o3, L2, or L3 groups must be universal instead of global. It is most likely that all the members of each o1 and L1 group are in a single domain, so all o1 and L1 groups can be local.
-
In the unlikely event that, for example, the members of o1AcctPayable are in two domains, you must make that group universal. You must also make intermediate global groups, one in each domain, because due to excessive replication, users should not be directly in universal groups. You could call these intermediate global groups o0AcctPayableDomA and o0AcctPayableDomB. Note that these intermediate groups are not shown in Figure 3.38.
-
It is quite possible that either the organizational or geographical group structure more or less matches your OU structure. The group structure, however, has nothing to do per se with the OU structure. Also, the groups' locations in the OU tree don't affect how they work.
-
If your OU structure matches the geographical structure, for example, you can place each geographical group in the corresponding OU. This way the person who was delegated the administration of the Boston OU, for example, can manage both the Boston users and the L1Boston group. And the person who is responsible for the Massachusetts OU can put L1Boston and L1Cambridge into L2Massachusetts.
-
If you have no use for one of the largest groups in Figure 3.38, such as L3USA, you can obviously choose not to create it at all.
If you feel you have the need, you can also nest the resource-oriented (domain local) groups. For example, you can create a group for each color printer and then a larger group to cover several color printers. See Figure 3.39 for an illustration.
)
Figure 3.39 To simplify permission management, you can create a domain local group (or a local group in a member server) for each color
printer and then assign a larger color printer group to each per-printer group.