Creating and Managing Groups
It's much easier to administer a network when you can manage several users at once. We can expect that all members of a given section of an organization will have the same needs in accessing data or using printers, and it's also likely that they should be subject to the same security restrictions. Rather than granting individual users the rights to print to a particular printer or to update files in a given folder, we can allocate those rights to a group object. Making user accounts members of the group automatically grants them any rights that group object has.
Windows Server 2003 has a number of different ways of defining groups of user accounts. We'll describe the different methods a little later, but first you have to understand that Windows Server 2003 domains can be in four different functional levels, and those levels impact what types of groups are possible and what nesting of those groups can be done. (The functional levels have implications related to other capabilities as well, such as Active Directory replication efficiencies, but we're only interested in group behavior here.)
The Four Domain Functional Levels
When the Windows Server 2003 version of Active Directory is installed, a basic set of features is enabled that allows the new domain controller to retain backward compatibility with older domain controllers running Windows NT 4.0 or Windows 2000. As these older domain controllers are removed from the network, the administrator can enable the additional features by raising the domain functional level. The domain functional level determines what features are available and whether or not older domain controllers are supported. Here are the four domain functional levels:
Windows 2000 mixedThe default level in Windows Server 2003, this level is equivalent to mixed mode in Windows 2000. At this level, a domain can contain domain controllers on computers running Windows NT, Windows 2000, or Windows Server 2003. This flexibility comes with a price, as you'll see, because at this level you cannot use the enhanced group features available in either Windows 2000 or Windows Server 2003.
Windows 2000 nativeOnce you have removed all Windows NT domain controllers from the domain, you can increase the domain functionality level to Windows 2000 native. At the Windows 2000 native level, you get the improved group capabilities of Active Directory as delivered in Windows 2000, such as the ability to "nest" groups and the availability of groups of Universal scope.
Windows Server 2003 interimBoth Windows NT and Windows Server 2003 domain controllers can exist in a domain at this level. As with the Windows 2000 mixed level, enhanced group functionality cannot be used.
Windows Server 2003Only domains that have no Windows 2000 or Windows NT domain controllers can be raised to this level of domain functionality. This is the most advanced level of domain functionality. Although important enhancements are achieved in upgrading from Windows 2000 to Windows Server 2003 Active Directory, there are no significant differences in group functionality between the two levels.
Figure 3.23 shows raising the domain functional level.
Figure 3.23 Raising the domain functional level.
Active Directory Functional Levels
In fact, several capabilities are only available when in the Windows Server 2003 functional level, including improved Active Directory replication and schema handling. In this section, we're only interested in the effect the domain functionality level has on groups.
Raising Functional Levels
This step is not reversible, so it should be initiated only on a production network by an experienced network administrator.
Expect Functional Level Questions
Expect several exam questions that deal with the topic of the different features enabled at different functional levels.
The two types of groups are distribution groups, which only are used for email lists, and security groups, which can be used both for email distribution and resource access. You choose the type depending on the reason you are creating the group:
DistributionUsed for email distribution lists only. Cannot be assigned permissions to use resources.
SecurityUsed both for assignment of permissions to use resources and for email distribution.
The second way of classifying a group is by defining its scope. Group scope means determining where the group members and the resources that the group can be granted access permissions to reside. Table 3.3 lists the scope of the group object in the first column (Domain Local, Global, and Universal); in the second column, the object types that can be members of this kind of group; in the third column, the locations of the resources that a group can be given access to.
Note that in several cases, the characteristics of the group object differ depending on the functionality of the domain.
Table 3.3 Group Scopes and Applicable Members and Rights
Can Be Granted Access to Resources In
Accounts, global groups, and universal groups from any domain, and, in Windows 2000 native or Windows Server 2003 functional level domains, other domain local groups from the same domain as the group object.
The local domain
In domains at the Windows 2000 mixed level or at the Windows 2003 interim level, only accounts from the same domain as the group object. In Windows 2000 native or Windows Server 2003 functional level domains, accounts and other global groups from the same domain as the group object.
Any domain in the forest and any domain in any other forest that trusts the local domain
(Not available in domains at the Windows 2000 mixed level or the Windows Server 2003 interim level.) Accounts, global groups, and universal groups from any domain.
Any domain in the forest and any domain in any other forest that trusts the local domain
How would you choose the scope of a group you need to create? Let's talk about each scope in turn.
Domain Local Groups
Groups of the Domain Local scope are typically used for resource access. When creating a group of this scope, you think of the resource that we're granting access to, rather than the users who might use the resource. You also name the group object after the resource. You might create a Domain Local group with the name DL-CalgaryEngineeringResources, for example. You would grant this group Read and Write access to the folders and printers that are used by engineers in Calgary. The members of the group can be (refer back to Table 3.3) user accounts, global groups, and universal groups from any domain trusted by this domain.
Understand Groups and Scope
Expect at least one exam question that deals with the scope of groups in Windows Server 2003. Microsoft has always tested heavily on the different types of groups and their scope. This exam will probably not be any different.
If the domain is at the Windows 2000 native functional level or the Windows Server 2003 functional level, the new group can also have other domain local group accounts among its members. The ability to make a group a member of another group of the same type is called nesting.
We have just listed the types of objects that can be members of our new domain local group, but what types are we likely to use? Typically, the member list of a domain local group includes an administrator account and one or more global group accounts. More rarely, you may also see universal group accounts in the domain local group member list.
Scope of Trusts
A domain trusts all other domains in its forest and any other domains that the administrator has explicitly set the domain to trust.
The ability to nest groups is very useful in administration. With nesting, you could define a G-CalgaryUsers group, whose members are groups called G-CalgaryPersonnel, G-CalgaryEngineers, and G-CalgaryHR. You would make the user accounts members of the departmental groups, with no need to also make them members of the city group.
A global group is used to collect user accounts, typically according to the function the members perform in their work. Therefore, their names reference the accounts that are on the group member listtypical global group names are G-CalgaryEngineers and G-VancouverHR. Only accounts in the same domain as the group object can be members of the global group. The reason the group is called "global" is that the group can be assigned access to any resource or made a member of any domain local group in the entire forest.
If the domain is at the Windows 2000 native functional level or the Windows Server 2003 functional level, the new group can also have other global group accounts from its domain among its members.
A good example of the use of Global groups is when users are disbursed and resources exist in few domains. For example, an engineering company has engineers in its Vancouver, Calgary, and Edmonton offices. Each location hosts its own domain in a Windows Server 2003 Active Directory forest. All engineering resources are located in the Calgary domain. Each domain administrator places his engineers in an "engineers" Global group for his domain. The Calgary domain administrator creates the EngRes Domain Local group and assigns the selected permissions to that group. He then places each Engineers Global group from each domain into the EngRes group. The Calgary administrator relies on the other administrators to determine who in their respective domains is allowed access to the resources.
A universal group, as its name implies, has no limitations as to where its members are located, or in what domains it can be granted resource access. Its members can come from any trusted domain, and it can be a member of any group or granted access to resources in any trusted domain. These qualities make the group type seem ideal: no worrying about whether the source of members is all right or whether the group can be assigned access in another domain.
There is a cost to this universality, however: The list of members of a universal group is kept in the Global Catalog (GC) and therefore is replicated to all domain controllers designated as Global Catalog servers in the forest. However, the new link-value replication feature in Windows Server 2003 reduces the amount of replication traffic significantly, compared to Windows 2000, where the entire Universal group membership list was replicated whenever a change was made.
The Global Catalog of a forest is a directory that contains a subset of each of the objects in every domain of the forest, though only some of the properties of each object. Although the main purpose of the Global Catalog is to provide an index for forestwide searches, it is also used during authentication (the process of ensuring that an object has the right to access the resources it is requesting) to get the list of all the groups a user object is a member of.
You create a universal group when both these conditions apply:
The members of the group come from more than one domain.
The group needs resource access in more than one domain.
Universal groups are useful when users and resources are disbursed in all domains. For example, when every domain has EngRes and Engineer Global groups, this might not be bad during the initial setup, but it becomes a nightmare as new domains are added. The Universal groups make it easier, in that each domain's Engineers Global group gets added to the Engineers Universal group, and the Engineers Universal group is added to each domain's EngRes Domain Local group. As new domains come online, they only have to add their Engineers Global group to the Engineers Universal group, and the Engineers Universal group to the Domain Local group that they have assigned permissions for the shared resources to.
Recommended Sequence of Groups
In small networks (a single domain, with one domain controller), you could work exclusively with groups of global scope. Any user account within the domain can be a member of a global group, and global groups can be given access to resources anywhere within the domain.
In larger networks, the recommended usage of groups is as follows:
Make accounts members of global groups.
Make global groups members of domain local groups.
Assign resource access permissions to the domain local groups.
In some cases it is helpful to make global groups members of universal groups and then to make the universal groups members of domain local groups. This is only necessary when a universal group is neededthat is, when a group will have members from multiple domains and will need access to resources in multiple domains.
This sequence is known as AGUDLP, which stands for Accounts, Global, Universal, Domain Local, and Permissions.
Here's the hierarchy, then: Say we have three domains (Lantrainers, Lanwriters, and Lanconsultants), and there is a global group in each domain that holds all the finance mangers in that domain (Lantrainers/G-FinanceManagers, Lanwriters/G-FinanceManagers, and Lanconsultants/G-FinanceManagers). We could make the U-FinanceManagers universal group with these three global groups as members, and then place the universal group on the member list of a domain local group in each of the domains, to give the finance managers access to the resources the domain local group provides. Finally, we could add U-FinanceManagers to the member list of the DL-FinanceResources domain local group in each domain.
You might wonder why we don't grant access to the resources directly to the universal group. We could, of course, but our assumption is that the domain local groups would exist already, to give access to the resource to groups within the local domain.
This hierarchy of groups allows very simple handling of new employees. When a new finance manager joins any of the companies, the local administrator needs only to make the finance manager's user account a member of the G-FinanceManagers global group in the new user's local domain, and that user will immediately be able to access the resources needed.
Creating and Modifying Groups by Using the Active Directory Users and Computers Console
To create a group with Active Directory Users and Computers, first select the domain or OU where you want the group object to reside. Generally you should place the group objects inside OUs because you will most likely delegate responsibility for all the objects in an OU to a subadministrator. In our sample company, it has been agreed that any domain local group that has members from outside the domain will be created at the LTI level. Also, global groups will be created at the level in the hierarchy above all the objects in the groups' member list. So the DL-FinanceResources domain local group is created at the LTI level, as is G-FinanceManagers. The G-CalgaryEngineers group would be created at the Calgary OU level.
In Step by Step 3.3, we'll create groups with Domain Local, Global, and Universal scope.
STEP BY STEP
3.3 Creating Groups with Domain Local, Global, and Universal Scope
Open Active Directory Users and Computers.
Right-click the LTI Organizational Unit.
Select New, Group from the context menu.
When the dialog box opens, ensure that the Domain Local and Security radio buttons are selected and then type the name DL-FinanceResources (see Figure 3.24).
Click OK, and the group object is created.
Right-click the LTI Organizational Unit again and select New, Group from the context menu.
This time, ensure the Global and Security radio buttons are selected and then type the name G-FinanceManagers and click OK.
Right-click the LTI Organizational Unit a third time and select New, Group from the context menu.
This time, ensure the Universal and Security radio buttons are selected and then type the name U-FinanceManagers and click OK. Now we have our three groupsand in production we would create several others (see Figure 3.25).
Now we want to make G-FinanceManagers a member of U-FinanceManagers, and we want to make U-FinanceManagers a member of DL-FinanceResources.
Right-click the U-FinanceManagers object and choose Properties. Select the Members tab.
Click Add. In the Select Users, Contacts, Computers or Groups dialog box (in the Enter the Object Names to Select area), type G and click Check Names. A dialog box appears listing all the users, contacts, computers, or groups whose names start with G (see Figure 3.26).
Select G-FinanceManagers and click OK. G-FinanceManagers is now a member of U-FinanceManagers. In production we would also add the G-FinanceManagers global groups from the other domains as well.
Now click the Member Of tab. Select Add, type DL in the Enter Object Names to Select area, and click Check Names. Select DL-FinanceResources and click OK.
We now want to create the \\MARS\Finance share and give DL-FinanceResources access rights to it. To do this, start the Share a Folder Wizard by clicking Add Shared Folder from the Manage Your Server application.
After selecting the folder to be shared, naming the share Finance, and assigning a share name, choose Use Custom Share and Folder Permissions, and in the dialog box click Add and browse to the DL-FinanceResources group. Assign the group Full Control rights, remove the Everyone group from the list, and click OK.
Figure 3.24 Give the group a name and specify its type and scope.
Figure 3.25 The group objects are shown in the details pane for the Organizational Unit in which they were created.
Figure 3.26 Select the group you want and click OK.
We have accomplished our task. Any member of the G-FinanceManagers global group will have the correct access to the \\MARS\Finance share.
Identifying and Modifying the Scope of a Group
Now you know that the scope of a group object in a domain can be Domain Local, Global, or Universal. (On a member server, standalone server, or workstation, local groups can also exist.) So how can you tell the scope of a group object?
The first thing to know is that it won't help you to look at the icons in the details pane of Active Directory Users and Computers. The icons used to denote group objects of all scopes are the same. However, the Type column in the details pane does indicate both the group scope and the group type. See Figure 3.25 to confirm this.
What if you want to change the scope of a group? Perhaps you have a global group, and you have realized that it would be useful to add accounts from another domain to the member list. That's not possible with a global group, but it is with a universal group. If you can change the scope to universal, you can add members from domains in different parts of the enterprise and retain the domain local memberships the existing group has.
If the domain functionality level of your domain is Windows 2000 mixed or Windows Server 2003 interim, you cannot change a group's scope. Universal groups are not available at that domain functionality level, and you cannot change a group's scope from domain local to global, or vice versa.
If the domain functionality level is Windows 2000 native or Windows Server 2003, you can change a group's scope, but only if the group is not a member of another group and has no group members that would be illegal for groups of the new scope.
Here are some examples:
You want to change the scope of a group from Global to UniversalThis is not allowed if the group is a member of another global group.
You want to change the scope of a group from Domain Local to UniversalThis is not allowed if the group has another domain local group as one of its members.
You want to change the scope of a group from Universal to GlobalThis is not allowed if the group has another domain local group as one of its members.
You want to change the scope of a group from Universal to Domain LocalThis is allowed under all conditions.
Note that it is not possible to change a domain local group to a global group, or vice versa. To change a group's scope with Active Directory Users and Computers, first you have to select the group and look at its properties. Simply click the radio button beside the new scope and click OK to change the scope. If you have followed group naming conventions that indicate the scope of the group, you will probably want to rename the group to show the new scope.
To determine the scope of a group object from the command line, you can use dsget. This command shows the description of a group, whether its type is security, and its scope:
dsget group <dn> [-desc] [-secgrp] [-scope]
To change a group's scope from the command line, you can use dsmod. Its syntax in this case is very simple; you just type this:
dsmod group <dn> -scope <L, G, or U>
You need to be a member of Domain Admins, Enterprise Admins, or Account Operators, or you have to been delegated the appropriate authority to change the scope of a group by either method.
Managing Group Membership
You can make an account a member of a group in two ways:
By starting with the properties of the account and changing the list of groups of which the account is a member
By starting with the properties of the group object and changing the member list of the group
There are several methods for changing the group membership, both from Active Directory Users and Computers and from the command line.
In Active Directory Users and Computers, you can use the Member Of tab of the account to see the list of groups the account belongs to, or you can use the Members tab of the group to see the list of members.
Let's look at the "Member Of" method first. Choose the properties of a user, group, or computer object in Active Directory Users and Computers and then click the Member Of tab. A list of group objects is displayed. Click Add and use the Object Picker to locate the group or groups you want the account to be a member of. Click OK, and the Member Of list is updated, as shown in Figure 3.27.
Figure 3.27 Click Add to make the user a member of an- other group.
Another way to use Active Directory Users and Computers to add accounts to a group is to select multiple accounts and then choose File, Properties and click the Member Of tab. With the Object Picker, find the group whose member list you want to add the accounts to, select it, and select OK. Alternatively, you can right-click the objects and choose Add to a Group from the shortcut menu.
Now let's try starting from the group object. Display its properties and choose Members. Use the Object Picker again, but this time the goal is to find the accounts that should be added to the member list of the group. Select the objects and click Add.
A third method (but not recommended) is to select the accounts you want to add to a group's member list and then drag them to the group object. Dropping the accounts on the group object adds them to the member list. This method is not recommended because it is too easy to drop the accounts on the wrong group object.
Adding Accounts to Groups with Command-line Tools
Naturally, a command-line tool is also available for this purposeyou can change the member list of a group with the dsmod group command. This command adds the accounts whose distinguished names follow addmbr to the member list of the group specified:
dsmod group <groupdn> -addmbr <dn's of accounts to be added>
Note that dsmod group has two similar-looking parameters that can be used to alter the membership list of a group. As you can see from Table 3.4, -chmbr and -addmbr both change the membership list, but with quite different results.
Table 3.4 The chmbr and addmbr Commands
Member List Before
Member List After
Jack, Barbara, Gill, Catherine
Jack, Barbara, Gill, Catherine, John
Jack, Barbara, Gill, Catherine
dsmod with the addmbr parameter adds the account to the member list of the group, whereas the chmbr parameter replaces the current member list with the accounts following chmbr. And dsmod group with the rmmbr parameter removes the accounts listed from the group's member list.
You're probably expecting to find that there is a command-line method for adding a member to a group using dsmod user. There isn't! In the Active Directory Users and Computers interface you cannot tell whether the group membership information is a property of the user object or the group object. But because dsmod only allows group membership changes with dsmod group, it is clear that the membership information belongs to the group object.
Group Membership Changes
As in all previous versions of the Windows server products, the group membership information is rebuilt when the user logs on. After you have changed group membership for users, be sure to tell them to log off and on again to see the effect of the group membership change.
Users on the Local Computer
Although we have been talking about domain users and domain groups in this section, you may find you need to create users and groups at the local computer level, too. Here are some examples:
A member server in a domain may need a group account to provide access to the resources on that computer.
You might need to share a printer installed on a standalone server, and you want to create a local group account to permit this.
You have a computer running Windows Server 2003 that is not part of a domain, and you want to define users and groups to allow access to its resources.
These tasks are performed using Local Users and Groups in Computer Management or with the net localgroup command. Once the users and groups have been created, you can grant them rights to access resources on the computer.
Finding Domain Groups in Which a User Is a Member
If you want to know what groups a user belongs to, you can easily find out with Active Directory Users and Computers by looking at the properties of the user object and then selecting the Member Of tab. There you will see the groups the user belongs to.
There is a problem, however. What if the user is a member of group A, and group A is a member of group B? In that case, the user is effectively a member of group B, but that fact is not shown on the Member Of tab of the properties of the user object. In fact, there is no way within Active Directory Users and Computers to show the expanded member list. However, we can use dsget user to show this information.
To find all the groups the user belongs to, not counting those due to group nesting, use the following dsget command:
dsget user <dn> memberof
To find all the groups the user belongs to, including those due to group nesting, use the following dsget command:
dsget user <dn> memberof expand
In Figure 3.28, you can see the output of these two commands for the same user.
Figure 3.28 The first command shows the direct group memberships of the user, whereas the second shows the nested memberships as well.
Do you remember the discussion of piping earlier in this chapter? We can pipe the output of one command to another command, which will allow us to avoid having to know the distinguished name of an account in memberof queries. Look at Figure 3.29.
Figure 3.29 We only need to know enough of the user's name to make the -name parameter unique.
As you can see from the figure, it was sufficient to enter najma* to select the one user whose group memberships are wanted.
Creating and Modifying Groups by Using Automation
Earlier in this chapter, we described using ldifde to create and modify user accounts. ldifde can also be used to create and modify group accounts.
In Step by Step 3.4, we will list the group accounts in the Vancouver OU, modify the names to create new group accounts, and add user accounts to the group accounts.
STEP BY STEP
3.4 Creating Group Accounts
Open a command prompt and change to the root of the C: drive.
Type the following command:
Type notepad ldifgroupout.txt to open the file in Notepad.
Change the names of the groups to new onesfor example, Marketing and Production in place of Sales and Engineering.
Remove the entry for VancouverUsers.
Save the file as ldifgroupin1.txt.
Type the following command:
In Notepad, create a file called ldifgroupin2.txt, to change the member list of the Vancouver Users group, with the following content (note that ldifde can only replace the complete member list of a group, so you have to include all members in this file):
At the command prompt type the following command:
In Active Directory Users and Computers, view the group objects in the Vancouver OU to see that the Marketing and Production groups have been created and that the four groups listed in ldifgroupin2.txt are shown as members of the Vancouver OU.
ldifde -f ldifgroupout.txt -d "OU=Vancouver,OU=LTI,DC=lantrainers, DC=local" -l objectclass,cn,distinguishedname,name, samaccountname -r "(objectclass=group)"
This command will change the OU's distinguished name appropriately, if necessary, and list the group names in the ldifgroupout.txt file.
ldifde -i -f ldifgroupin1.txt -j c:\ -k
-j c:\ puts a log file called ldif.log on c:\, and -k tells ldifde to continue in case of errors. You should see the message 2 entries modified successfully.
dn: CN=Vancouver Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local changetype: modify replace: member member: CN=Sales,OU=Vancouver,OU=LTI,DC=lantrainers, DC=localmember: CN=Engineers,OU=Vancouver,OU=LTI, DC=lantrainers,DC=localmember:CN=Marketing,OU=Vancouver, OU=LTI,DC=lantrainers,DC=local member: CN=Production,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local -
ldifde -i -f ldifgroupin2.txt -j c:\ -k
You should see the message 1 entry modified successfully.