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.