Windows 2000 User Groups

You need to understand several concepts about user groups in Windows 2000/.NET before you begin to create them. Groups are helpful because they simplify administrative tasks when you have groups of users that must be treated similarly when it comes to rights and permissions. Second, because groups can be limited in scope, they can be useful for security purposes, limiting the computers or domains in which a user can be granted access.

Choosing a Group Based on the Group's Scope

Groups each have a scope, which is basically the area of the domain or global forest that the group covers. By having several types of groups, each with its own particular kind of membership and scope, you can put together combinations that should solve most of your administrative needs for managing users with similar needs. The types of groups, and the scope implied by each, are as listed here:

• Domain local group—These groups are limited to just the domain in which they are created. Users can be placed into these groups for local domain management purposes.

• Global group—These groups are made up of users or groups from a single domain but are used to grant access for the members of the group in other trusted domains. Think of this as a way to "export" users to allow them access to resources in other domains.

• Universal group—This type of group can contain user accounts and global group accounts from any trusted domain that exists in the Active Directory forest. This is similar to a global group but allows members of the group to be granted permission to resources in domains throughout the entire forest.

As described previously, groups can be members of other groups just like users, and this is where things can become a little complicated. For example, a domain local scope group can have the following as members:

• Groups that have global scope—You place the global group into a local group and then manage the local group when granting rights and permissions.

• Groups that have universal scope—Again, you can place universal scope groups into a local group and then use the local group for management purposes.

• Groups with domain local scope—Other domain local scope groups can be placed in a domain local scope group.

• User accounts—You can put individual users into a group with domain local scope.

Note that the domain local group does not have to have just one of the preceding groups (or users) as its members. You can combine any of the preceding and place them into a single domain local scope group, and then use the group to manage the members of these other groups locally in your domain.

A domain local group is a very useful management tool. For example, if you have a particular resource that several users share, place the users in the group and grant the group the necessary access to the resource. The resource can be a folder or a file, or perhaps a printer. If the resource changes in the future (for example, you decide to use a new file server for a particular set of files), you have to

change permissions only on the group to let the group members access the new resource. Otherwise, you'd have to modify the permissions for each individual user, which in a large environment can be an almost impossible task if your network changes frequently.

Unlike domain local groups, global groups can have as members only users or other groups from within a single domain. Yet global groups can be granted access to resources in other trusted domains. This enables you to package a group of users that need similar treatment in other domains when it comes to resource permissions.

Universal groups also can be used to grant permissions in multiple domains—throughout the forest of domain trees. Note that these groups are available only if you have an Active Directory structure that is part of a multidomain forest. They serve no purpose in a single-domain tree because domain local groups and global groups provide the necessary functions in a single-domain tree.

The membership of a universal group should not change on a frequent basis. This is because when a universal scope group's membership changes, the entire list of members is replicated to every global catalog in the forest of trees. Use universal groups for grouping users and other groups that are more stable in membership. Although global groups enable you to create groups of users and other groups that can be granted access in trusted domains, their membership must come from a single domain. To make managing a universal group easier, first place users into global groups in their own domains,and then place these global groups into a universal group. Thus, when the membership of a global group changes, there is no need to replicate the universal group membership to every other global catalog. Only the global group has changed. The universal group has as its member the global group, not the individual users who come and go from the global group.

Assigning User Rights for Windows 2000, Server 2003, and XP

Users who are logged in to a Windows 2000, Server 2003, or XP computer can be granted rights by the administrator of the computer. If the user logs in to a domain account instead of the local computer, a domain administrator can manage these rights. Rights granted to an account that resides on an individual Windows computer protect access to resources on that computer only. The security information for the computer is stored locally, in the Security Accounts Manager (SAM) database, and applies only to resources on that local system.

Accounts that are created on a domain controller can be used when assigning user rights to resources on computers throughout the domain. And, by placing users into groups, you can easily manage a number of users who need the same access to resources or the same rights. This is done by granting the rights to the group, instead of individual users. If a user needs access to resources that are not granted by the group membership, you can place the user in more than one group. Because groups enable you to simplify granting rights to users, the following discussion will concentrate on those rights.

Starting with Windows 2000, most Administrative Tools are snap-ins for the Microsoft Management Console (MMC). By using the MMC to create management tools, you'll find it easy to switch from one MMC console to the next, without having to relearn the mechanics of the particular utility. For example, when using MMC you'll find two panes on the screen. The left pane contains a tree of objects that can be managed. An Action menu presents you with functions you can perform. The right pane is used to display different kinds of information, based on the particular utility and the actions you take. The MMC allows you to create new utilities by installing a snap-in that is appropriate for the functions you need to perform. However, most of the tasks you will use to manage thecomputer or domain have already been set up as an MMC application. Other snap-ins, which are used for more sensitive operations, such as altering the Active Directory schema, must be created by installing the snap-in.

Windows NT defined certain basic rights you could grant to a user account, as well as a set of rights that were granular. The basic rights were simply combinations of these granular rights. In Windows Server 2003, rights have been divided into two categories. These are logon rights and privileges. Logon rights are few in number, and can generally be used to manage most users or groups.

These logon rights are listed here:

• Allow log on through Terminal Services—Enables a user of a computer to log on using Microsoft Terminal Services. Essentially, a Terminal Services client runs programs on a server designated to supply this service, and the Terminal Server client computer displays the GUI interface for the application. This enables you to use older computers with fewer resources (such as memory or processor speed) to be used in your network.

• Allow log on locally—Enables a user to log on locally at a workstation or server; that is, to log on sitting at the workstation or computer, not using a network connection. Generally, administrators are the only users who can log on locally at a server.

• Access this computer from a network—Enables a user to log on to the computer from the network. In other words, this gives the capability to make a network connection, such as to access a file share on the computer.

• Log on as a batch job—Allows a user to submit a batch job (using the task scheduler) that will run under the user's account. Unless you deny this right, the default allows users to submit batch jobs to run in the background. Batch jobs are used to perform specific functions at a certain time, unlike services that run in the background and respond to certain system or user

events.

• Log on as a service—Thisright allows the user to start a service using his or her account. A service is a process that runs in the background continuously.

• Deny log on as a batch job—Preventsan account from running a batch job on the computer.

• Deny log on as a service—Prevents an account from being used to run a service (a background process that runs without a GUI interface).

• Deny log on locally—Isthe opposite of the Allow log on locally right. This right overrides the Allow log on locally right.

• Deny access to this computer from network—Isthe opposite of the Access this computer from the network right. This right overrides the Access this computer from a network right.

• Deny log on through Terminal Services—Isthe opposite of the Allow log on through Terminal Services right.