What about Groups? | Windows Server 2003 for Dummies

A group is a collection of users who need similar levels of access to a resource. Groups are the primary means by which Windows Server 2003 domain controllers grant user access to resources.

Groups simplify the administration process by reducing the number of relationships that you have to manage. Instead of managing how each individual user relates to each resource, you need to manage only how the smaller number of groups relate to resources and to which groups each user belongs. This reduces the workload by 40 to 90 percent. Windows Server 2003 has a Best Practices section under its Help guide that encourages you to use groups in as many situations as you can.

A group is nothing more than a named collection of users. There are two different types of groups, and each type can have any one of three scopes:

Security groups are used to assign user rights to objects and resources in Active Directory. A secondary function of a Security group is that it can also be used to send e- mails to all the members of the group.
Distribution groups are used only for sending e-mail to all the members of the group. Distribution groups can't be used to define permissions to resources and objects in Active Directory.

Both group types can have any of the following scopes:

Global groups exist on a domain level. They are present on every computer throughout a domain and are managed by any Active Directory for Users and Computers tool hosted by Windows Server 2003. When the domain is running in Windows 2000 native mode or Windows Server 2003 mode, members of global groups can include accounts and global groups from the same domain. When the domain is running in Windows 2000 mixed mode, members of global groups can include accounts from the same domain.
Domain Local groups exist only on a single computer. They aren't present throughout a domain. When the domain is running in Windows 2000 native mode or Windows Server 2003 mode, members of Domain Local groups can include accounts, Global groups, and Universal groups from any domain, as well as Domain Local groups from the same domain. When the domain is running in Windows 2000 mixed mode, members of Domain Local groups can include accounts and Global groups from any domain.
Universal groups extend beyond the domain to all domains in the current forest. When the domain is running in Windows 2000 native mode or Windows server 2003 mode, members of Universal groups can include accounts, Global groups, and Universal groups from any domain. When the domain is running in Windows 2000 mixed mode, security groups with a Universal scope can't be created. When the domain is running in Windows 2000 native mode or Windows Server 2003 mode, Universal groups can be created and used to house other groups, such as Global groups, to facilitate the assignment of permissions to resources in any domain in the forest.

The three group scopes simplify the user-to-resource relationship. Using groups greatly reduces the management overhead for medium and large network, but it may seem a bit complicated for a small network. You can use groups like this:

Local groups are assigned access levels to resources.
Users are assigned membership to a Global group or a Universal group.
A Global group or a Universal group is assigned as a member of a Local group.

Therefore, users are granted access to resources by means of their Global or Universal group membership and, in turn , that group's membership to a Local group has access to the resource. Whew, now it's time for a drink!

Here are a few important items to keep in mind about groups:

A user can be a member of multiple Global or Universal groups.
A Global or Universal group can be a member of multiple Local groups.
A resource can have multiple Local groups assigned access to it. Using multiple Local groups, you can define multiple levels of access to a resource from read/print to change/manage to full control.

Although it's possible to add user accounts directly to a Universal group, best practices dictate that you should add them only to Global groups and add these Global groups to Universal groups. When that membership changes in a Universal group, such as the addition or removal of user accounts or groups, the change must be replicated throughout the forest through the Global Catalog Servers. Adding and removing user accounts often from Universal groups will cause a great deal of forest-wide replication traffic on the network.

If you add a Global group to a Universal group, user accounts and nested Global groups can be added to and removed from the Global group without causing a single replication. This is because the membership of the Universal group hasn't changed. It still has the same Global group or groups in it. Only the membership of the Global group changes when you add or remove user accounts or nested Global groups.

Although you can assign a user direct membership to a Local group or even direct access to a resource, doing so subverts the neat little scheme that Microsoft developed to simplify your life. So, just follow this prescription and you'll be vacationing on the beach in no time.

REMEMBER

Whereas any other group can be a member of a local group, a Local group can't be a member of any other group when the domain is running in mixed mode. Domain Local groups can be placed in other Domain Local groups from the same domain when the domain is running in Windows 2000 native mode or Windows Server 2003 mode.

You manage groups on Windows Server 2003 using Active Directory Users and Computers. To create a group using Active Directory Users and Computers, follow these steps:

Click the domain to which you want to add the group, and then choose Action New Group.

The New Object Group dialog box appears.
Type the new group name .

The group name for pre-Windows Server 2003 machines is filled in automatically.
In the New Object Group screen, select the group scope: Domain Local, Global, or Universal.

Universal groups are powerful because they extend to all domains in the current forest.
Select the group type: Security or Distribution.

You'll almost never use the Distribution group setting because it does not contain the access control list (ACL) information necessary for security purposes. The Distribution group setting is used mainly for e-mail operations, where you would want to send an e-mail to a collective group of users and don't need security attached to it. We recommend always using the Security type.
Click OK.

After the group object is created, you can double-click the object to add more attributes to it. You see several new tabs called General, Members, Member Of, and Managed By. These tabs are fairly self-explanatory, but here's a little bit about them:

General: This tab contains the same information you filled in when you created the group, such as group name, description, e-mail, group scope, and group type.
Members: This tab shows the users who are members of the group. This is where you add users to the group.
Member Of: This is where you can add this group to other groups.
Managed By: This tab allows you to specify who manages the group. You can provide information about the user, such as name, address, and phone number.

You don't have to create your own groups: Windows Server 2003 domain controllers have several built-in Security Domain Local groups that you can use. The groups are in the Builtin container, by default. The following lists just a few of them (the default members are in parentheses):

Administrators (Administrator, Domain Admin, Enterprise Admin)
Guests (Domain Guests, Guests)
Pre-Windows 2000 Compatible Access (anonymous logon, Everyone)
Users (Domain Users, Authenticated Users)

Note that your screen may show that these built-in groups have more members than we've listed, depending on which services are installed on your server. For example, if you've installed Internet Information Services (IIS), you'll see more members in the built-in Guests group.

These default, built-in Security Domain Local groups have both predefined built-in capabilities (see Figure 15-6) and default user rights. You can modify the user rights of these groups (see this chapter's section titled "Users Have Properties"), but you can't change the built-in capabilities.

Figure 15-6: The built-in security groups of Windows Server 2003.

Windows Server 2003 domain controllers include the following additional security groups as well, which can be found in the Users container by default:

Cert Publishers (Domain Local)
Debugger Users (Domain Local)
HelpServicesGroup (Domain Local)
RAS and IAS Servers (Domain Local)
Telnet Clients (Domain Local)
Domain Admins (Global)
Domain Computers (Global)
Domain Controllera (Global)
Domain Guests (Global)
Domain Users (Global)
Group Policy Creator Owners (Global)
Enterprise Admins (Universal)
Schema Admins (Universal)

Other groups may exist, such as DnsAdmins, which would be created if the domain controller hosted DNS services. For the most part, however, the preceding list is inclusive for the forest root domain controller.

Windows Server 2003 has three more groups that it classifies as special identities: Everyone, Network, and Interactive. These are built-in groups that you can modify only indirectly. For example, the Everyone group may reflect a membership of 20 user accounts until you add another account to the domain. The user is automatically added to the Everyone group with no intervention by you. Therefore, although you did not specifically make the new account a member of the Everyone group, you did affect its membership. Guests are also added to the Everyone group, so be careful and modify the Guest account to restrict access to the network. (See the "Guests can wear out their welcome" section earlier in this chapter for more information.)

The Network group is for those who use the network as a means to access resources. When you give users access to resources across the network, they're automatically added to the Network group.

The other group, Interactive, represents users who access resources by logging on locally.

Again, you can't change who is a member of these groups in a direct sense. However, when you set permissions to resources, these groups will appear and you should modify the access levels of these groups to specific resources. For example, when giving users access to the root level of a volume, you can restrict access to the Everyone group so those users have only Read permissions.

Tip

You should create groups that make sense to your organizational pattern, method of operations, or just common sense. Groups should be meaningful, and their names should reflect their purposes. Naming a group Sales isn't very useful, but a name such as SalesPrintOnly is very informative. You should create groups so that users are divided by purpose, access levels, tasks , departments, or anything else you consider important. Remember that groups exist for your benefit, so try to get the most out of them.