Manage users easily with groups

Windows NT uses groups to manage users. This month I'll discuss the difference between global and local groups, and I'll explain how you can use groups to manage user accounts and assign permissions.

NT Groups
Groups in NT help you organize user accounts and simplify assigning permissions on resources. NT uses global and local groups. You can use a global group anywhere in the domain in which you define the group. Global groups organize users by department, job function, or security level. Local groups control access to resources. A local group is relevant only on the system on which you create it, unless you create a local group on a domain controller. Backup Domain Controllers (BDCs) do not have accounts databases, so you must create a local group on the Primary Domain Controller (PDC) and then replicated it to the BDCs. Thus, one local group exists on all the domain controllers.

Groups and Security
The concept of using groups to assign permissions is simple: You assign permissions to a group, and anyone who is a member of the group automatically has the group's permissions. Suppose you have an Accountants group that has permissions to read, write, and edit financial files. When you add a new employee to the accounting department, you make that person a member of the Accountants group. You do not need to figure out what permissions the other accountants have to assign the same permissions to the new employee. In fact, figuring out what permissions the other accountants have is difficult because of how NT security works. In NT, you set file and directory access on resources rather than users, as Screen 1, page 206, shows. A directory keeps a list of users who have permissions to read and write to and from the directory. When a user tries to access the directory, NT determines whether the user is on the list. Users do not have a list of which directories they can use. To get a list of the files and directories a user can access, you need a third-party tool such as Somarsoft's DumpAcl 2.7.16 (http://www.somarsoft.com) or Intrusion Detection's Kane Security Analyst for Windows NT (http://www.intrusion.com). Screen 2, page 206, shows an example DumpAcl permissions list. Microsoft's Small Business Server (SBS) uses the Microsoft Management Console (MMC) interface to show which files and directories a user can access. This feature will be available in NT 5.0, which uses MMC.

The access control lists (ACLs) for files and directories give members of a group the access they need, so you can add people to the group as necessary. You can also remove users from a group to revoke their access to the group's resources. This approach ensures that employees who leave a company will no longer have access to proprietary files.

Global and Local Groups
You define global groups on the PDC. Global group membership is a subset of domain users. Each user can belong to as many as 1000 total groups, although security is easier to track when users belong to only a few groups. The IS department often maintains global groups and communicates with the human resources (HR) manager and department heads to decide which groups users need to belong to.

You define local groups on each system that has resources to share. A local group is valid only on the system where you define it, so you might need to create local groups on all servers. For example, if you have financial information spread across several servers, you might create a local group called Finance on each server. Alternatively, you might create a local group called Budget on one server, a local group called Payroll on a second server, and a local group called Receivables on a third server. Department managers can set up a variety of local groups to control the types of permissions the groups have.

After you define global and local groups, you must set up the local groups' membership. Local group members can be users, or they can be the global groups. Thus, you place the Accountants global group in the Budget local group, as Screen 3 shows. Members of the Accountants global group inherit the permissions of that group, which inherits its permissions from the Budget local group.

You might be tempted to assign permissions for a resource directly to the global group. Suppose you have several accounting groups at branch offices. Each office has an NT domain, with a local Accounting group. If you grant directory permissions to each local group, you need to make sure that the permissions are consistent. The ACL for each resource lengthens and takes longer to scan when a user requests access. But if you place each domain's Accounting global group into the Budget local group, the global groups have the same permissions, and the ACL contains only one entry that lists the access privileges for the Budget local group. If you want to change the global group permissions, you can change the permissions for the local group, and the changes will apply to all users.

You can use the same principle to assign permissions to groups instead of users. If you assign permissions on a directory or file to dozens of users, NT must search a large ACL to check permissions. If you assign permissions to a group, NT searches a smaller ACL and compares the user security context (the list of groups to which a user belongs) with the groups that can access the resource.

Microsoft recommends the group strategy for assigning permissions. First, decide which users need access to a resource, and place the users in a global group. Then, decide what type of access the users need (e.g., read-only, change, full control), and assign these access rights to a local group. Finally, make the global group a member of the local group. This method of assigning permissions makes maintenance and performance optimization easier.

Multiple Group Membership
As I mentioned previously, a user can belong to as many as 1000 groups. If a user belongs to several groups that have different levels of permissions, the user accumulates the combined permissions of the groups. Thus, if a user belongs to a group that can only write files to a directory (e.g., for data entry) and a group that can only read files (e.g., for checking the data entry), the user can read and write files. However, if the user or one of the user's groups has an Access Denied setting on a resource in the ACL, the user will be unable to access the resource. Access Denied acts as a veto: The user cannot use the resource, regardless of permissions status. Novice administrators sometimes place an Access Denied setting on a directory for the group Everyone, intending to then grant permissions to specific users. These administrators quickly learn that the group Everyone includes everyone, including administrators.

Built-in Groups
Screen 4 shows the global and local groups that NT creates on installation. If you install a domain controller, you see the global groups. A standalone server or workstation has only the local groups. You can use these built-in groups for many administration tasks, and you can add groups as necessary to grant or limit access to your data and applications.

The most commonly used global and local groups are Domain Users, Domain Admins, and Domain Guests. Every user in your domain is automatically a member of the Domain Users group. Some administrators use this group as the lowest level of security, such as for open resources, because it is slightly more secure than granting resource access to the group Everyone. Domain Admins includes systems administrators. You can use the Domain Guests group to set up limited-access guest accounts for users so they do not have to log on under their names. If you are running Internet Information Server (IIS), move the Internet User account from the Domain Users group (its default location) to Domain Guests. Moving this account lets you grant broad permissions to regular users through the Domain Users group, and lets you restrict anonymous Internet users through the Domain Guests group to only a limited area in your network.

Other local groups include the Operators groups: Account Operators, Backup Operators, Print Operators, and Server Operators. These groups have special permissions and can simplify systems administration tasks.

Account Operators can manage domain user and group accounts and can add and delete users without contacting the NT systems administrator. In each department, make one person, such as the department head, an Account Operator, because the department head knows better than the network administrator who should be in which groups. Account Operators can administer group memberships, but they cannot make themselves part of the Domain Admins group.

Backup Operators have read-only access so they can read data from a disk and place the data on a backup tape. Even if a Backup Operator's file and directory permissions do not permit access to file contents, the Operator can read files as part of a backup operation. Likewise, a Backup Operator might not have permissions to write over files but can do so when restoring files. Some administrators let Backup Operators back up but not restore data, because the Backup Operators might accidentally write over a more recent file. In addition, if Backup Operators can restore a file to a different drive, they might find ways to bypass network security.

Print Operators can administer and troubleshoot printers. For each department, you'll want at least one Print Operator, perhaps the same person as the Account Operator.

Server Operators can perform system-level administration tasks, including backups and restores. The systems administrator's assistants might belong to this group.

Microsoft recommends that you create a global group on each domain to correspond to each of these built-in local groups. You can control group membership through the global groups, and you can use the local groups' permissions to help delegate systems administration tasks.

Rationale
It might seem redundant to have global and local groups. However, both types of groups make administering NT systems and networks easier. You will realize the most benefit from NT's group function if you implement a sound group policy when you first install your network.