Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Groups allow user accounts
to
be logically grouped together for administrative purposes. For
example, instead of granting Read access on a shared folder to three
separate user accounts, create a group that contains these accounts
and assign Read permission to the group. It may be more initial work
to do things this way, but if you later want to change the
users' access to Full Control, you can do it in one
step by granting this permission to the group instead of granting it
for each user individually. Also, if other users need these same
permissions in the future, you just make them members of the group
since members of a group receive whatever permissions have been
assigned to the group (a user can belong to more than one group at a
time).

The general strategy that Microsoft recommends for managing resource
access by user accounts is called AGP: organize user

A ccounts into

G roups to which suitable

P ermissions are assigned. A good way to begin
is to determine which user accounts in your domain require access to
the same file, printer, and other network resources. For example,
users in the customer support department might need access to the FAQ
share, so create a group called Support for this purpose.

However, in WS2003 it's a little more complicated
than this: there are different types of groups, and these groups can
have different scope. In addition, groups can contain not just user
accounts but also computers and other groups. In fact, groups can be
nested within groups in various ways, which can make for some rather
complex administration scenarios.

We'll first consider groups in an Active Directory
environment, followed by groups in a workgroup environment.

Domain Setting

In a domain environment groups are

fairly
complicated. There are two types of groups, three possible scopes,
and complex rules for group membership and how groups may be nested.

Group Types

There are two basic types of groups
in an Active Directory environment:

Security groups

Used primarily to control the access that users have to network
resources but can also be used to send email messages to users.
Security groups in WS2003 correspond to the concept of groups in the
earlier NT operating system.

Distribution groups

Used only to send email

messages
to usersfor example, as distribution lists for
Microsoft's Exchange Server.

The rest of the discussion focuses solely on security groups.

Group Scopes

The scope of a group defines

restrictions
on the membership and use of the group. There are three different
scopes that security groups can have:

Global groups

These groups can be used

to grant
access to resources in any domain in the forest and are typically
used to organize users who have similar needs for accessing
resources. For example, you could create a Marketing global group and
make all employees in the marketing department members of this group,
since they all need to access the same file and print resources, web
sites, applications, and so on. Global groups in WS2003 are similar
to global groups in NT when used in domains whose domain functional
level is W2K mixed.

Domain local groups

These groups can be used
to access resources in the local domain
only. For example, if you want users in the

mtit.com domain to be able to access the

Pub shared folder in the same domain, you can
create a domain local group called PublicUsers, make selected users
or global groups members of it, and assign suitable permissions to it
for accessing the resource. Domain local groups are similar to local
groups in NT when used in domains whose domain functional level is
W2K mixed.

Universal groups

These groups

can be used
to access resources in any domain in the forest. They differ from
global groups in that they are available only in WS2003 domains
running in native mode, not mixed mode. Also, their membership can be
drawn from any domain, whereas global group members can come only
from the group's own domain. Universal groups are
new to WS2003 and have no corresponding type in NT.

WS2003 also has a fourth type of group scope called local groups. Local groups exist only in a workgroup environment and are discussed later in this section.

Group Membership

The membership that

different group scopes are allowed
depends on the domain functional level of the domain they are created
in.

Windows 2000 Mixed

In the Windows 2000 mixed domain functional level, the rules for
group membership are essentially the same as the rules in NT for
backward compatibility (allowing for the fact that WS2003 trusts are
transitive), specifically:

• Domain local groups can contain domain user and computer accounts
  from any domain in the forest and global groups from any domain in
  the forest.

• Global groups can contain only domain user and computer accounts from
  their own domains.

• Universal groups aren't available in mixed-mode
  domains.

Windows 2000 Native or Windows Server 2003

In the Windows 2000 native or Windows Server 2003 domain functional
levels, the membership rules for different group scopes are much more
complicated, as outlined in Table 4-13. As you can
see, the membership restrictions for domain local and universal
groups are the same. The difference is that domain local groups can
be used only to access resources in the local domain while universal
groups can access resources in any domain in the forest.

Nesting of Groups

Nesting means making one

group a
member of another. Nesting lets you reduce the number of times
permissions must be assigned in order to grant users access, but it
can also make group permissions more hidden and obscure. Nesting
groups in a multidomain environment can also help reduce replication
traffic between domains. Rules for nesting groups also depend on the
domain functional level.

Windows 2000 Mixed

The rules for nesting groups in domains running in Windows 2000
domain functional level are essentially the same as in NTthat
is:

• You can nest global groups within domain local groups.

• You can't nest global groups within each other or
  domain local groups within each other.

In other words, groups don't really nest at all in
mixed mode (or you could say they nest to one level only and, for
global groups, within domain local groups only).

Windows 2000 Native or Windows Server 2003

Nesting is a much more powerful feature when domains are running in
Windows 2000 native- or Windows Server 2003 domain functional level.
Table 4-14 summarizes the various ways in which
different group scopes can be nested in native mode domains. Note
especially that:

• Global groups can now be members of global groups. This is different
  from how global groups worked in NT.

• Domain local groups still can't be members of other
  groups.

It's also important to realize that, where nesting
is allowed, it can be performed to any level. In other words, you
could have an Enterprise Managers global group, which contains Branch
Managers global groups, which contain Division Managers global
groups, which contain Department Managers global groups, and so on.
This flexibility is almost too much of a good thing, and Microsoft
recommends that groups be nested no more than one or two levels.
Otherwise, permissions assignments may be difficult to track and
troubleshoot if problems arise.

Converting Scopes

WS2003 lets you convert


one type of group scope into another.
This gives you greater flexibility than you had in NT. However,
converting groups from one scope to another can be performed only on
domains whose domain functional level is Windows 2000 native or
Windows Server 2003. Otherwise, it would conflict with what you can
do in NT, which is what mixed mode is designed to support. Table 4-15 shows the various kinds of scope conversions
that can be performed on different groups in this scenario.

Using Groups

Careful planning is the key
to effective use of the different WS2003 group scopes. Again, the key
issue is which domain functional level is your domain running.

Windows 2000 Mixed

The mantra here is AGDLP, which means:

1. Create

   Accounts for your domain users within
   each domain.

2. Create

   Global groups within each domain to
   organize your domain users according to similar resource access needs
   or job description, and add your domain user accounts to your global
   groups as desired.

3. Create

   Domain Local groups in each domain to
   control access to specific sets of network resources within the
   domain, and assign appropriate

   Permissions for
   these resources to these groups.

4. Add global groups from various domains to domain local groups in each
   domain in order to grant access to these network resources to users
   everywhere in the forest.

This procedure is essentially the same as it was for NT-based
networks, except that domain local groups were called local groups in
NT (and thus the mantra was AGLP instead of AGDLP). Here is an
example to illustrate the principles involved:

Users in the marketing department need access to the color laser printer to produce their flashy spreadsheets. Other users in other departments may also need access to the printer. To accomplish this, create a global group called Marketing, and make users in the marketing department members of this group. Create a domain local group called ColorPrinter, and assign Print permission for the shared printer to the ColorPrinter group. Add the Marketing group to the ColorPrinter group.

A tempting shortcut to this procedure is to eliminate either the
global group or the domain local group from the process.
Here's an example:

Create a global group called Marketing, and make users in the marketing department members of this group. Assign Print permission for the shared printer directly to the Marketing group. This strategy may be described as AGP.

Alternatively:

Create a domain local group called ColorPrinter, and assign Print permission for the shared printer to the ColorPrinter group. Make users in the marketing department members of this group. This strategy may be described as ADLP.

The problem with the second and third strategies is that they
don't scale well if you later decide to add other
domains to your enterprise. In the first case, if you want to allow
users in a new domain access to the color printer in the local
domain, you will have to explicitly assign permissions to the
appropriate global group in the new domain instead of simply adding
the global group to the ColorPrinter group in the local domain. This
makes for somewhat more complicated administration. In the second
place, if you want to grant permissions for a printer in the new
domain to members of your local ColorPrinter group, you will again
have to assign these permissions explicitly since domain local groups
can't be members of any other groups.

Windows 2000 Native or Windows Server 2003

In native mode you can modify the AGDLP strategy somewhat since you
can also use universal groups whose scope of membership and resource
access span all domains in the forest. I call the mantra here AGUNP,
which means:

1. Create

   Accounts for your domain users within
   each domain.

2. Create

   Global groups within each domain to
   organize your domain users according to similar resource access needs
   or job description, and add your domain user accounts to your global
   groups as desired.

3. Create

   Universal groups to organize
   enterprise-wide users according to similar enterprise-wide resource
   access needs, and add your global groups from each domain to your
   universal groups as desired.

4. If you have large numbers of global groups, consider
   

   Nesting universal groups within other universal
   groups to reduce the number of members in any individual universal
   group.

5. Assign appropriate

   Permissions for accessing
   network resources across the enterprise directly to your highest
   level of universal groups (or assign permissions to domain local
   groups and place universal groups within domain local groups if you
   want to keep it complicated).

Alternatively, you can take advantage of the fact that the
performance issues relating to universal groups have been
considerably improved in WS2003 as compared to W2K Server. As a
result, you can often elect to use universal groups only when
grouping users together for administration. The resulting mantra
would then be AUNP, which means:

1. Create

   Accounts for your domain users within
   each domain.

2. Create

   Universal groups to organize users
   according to similar resource access needs, whether domain- or
   enterprise-wide in scope.

3. If you have large numbers of groups, consider
   

   Nesting groups within other groups to reduce the
   number of members in any individual group.

4. Assign appropriate

   Permissions for accessing
   network resources across the enterprise directly to your highest
   level of universal groups (or assign permissions to domain local
   groups and place universal groups within domain local groups if you want
   to keep it complicated).

Workgroup Setting

In a workgroup

environment,
groups are simple: there is only one type of group with simple
membership rules and no nesting.

Local Groups

Local groups allow

local user accounts in a workgroup
environment to be grouped together for administrative purposes. Local
groups are created in the same local security database where local
user accounts are created on a machine. Local groups are created
within the

Groups folder of the Local Users and
Groups node under System Tools in Computer Management.

Since use of local user accounts is usually confined to standalone
servers running WS2003 or client computers running XP, local groups
are used only in small networks. One possible use of local groups is
for several users to share a single standalone server or client
computer, and you can then secure files and folders located on that
machine. In this case you can create local groups to group local user
accounts together in order to manage permissions more easily. Another
use is to implement a WS2003 network using a workgroup model in which
each machine manages its own security settings.

Group Membership

Here are the membership


rules
concerning local groups:

• Local groups can contain local user accounts from the computer on
  which the group resides and global or universal groups from any
  domain.

• Local groups can't be members of other groups.

One confusing difference between WS2003 and NT is in the use of the
term

local groups . On NT, local groups:

• Are used to assign permissions to resources in the domain

• Can contain user accounts and global groups from the local domain and
  trusted domains

• Can be created on domain controllers, member servers, and workstations

However, on WS2003, local groups:

• Are not recommended for use in domain-based networks

• Can contain local user accounts from the local machine and global or
  universal groups from any domain

• can't be created on domain controllers

The long and the short of it is, where you used to use local groups
in NT, use domain local groups in WS2003 instead.

Built-in Groups

A number of special groups

are created
during the installation of WS2003. These built-in groups have
predefined sets of rights that simplify the job of administering user
accounts. For example, by adding a user account to the Administrators
built-in group, that user gains all the rights and privileges that
the special Administrator account has.

Different built-in groups are available, depending on whether you are
working with member servers or domain controllers and whether you
implemented your WS2003 environment as a workgroup or a domain.

Workgroup Setting

In a workgroup setting,

each standalone
server running WS2003 or client computer running XP has only one type
of built-in group availablenamely, built-in local groups.
These built-in local groups can be used to simplify the job of
administering the computer on which they exist. They control access
to resources on the local computer on which they exist as well as
granting users the rights to perform system tasks on this computer.
Built-in local groups exist within the Local Security Database on
standalone servers or client computers running WS2003. They are found
within the

Users folder of the Local Users and
Groups node under System Tools in Computer Management. The six basic
built-in local groups and their functions are as follows:

Administrators

Members can perform any administrative task on the local computer.

Backup Operators

Members can back up and restore the local computer.

Guests

Members have no rights or permissions on the local computer unless
they are specifically assigned.

Power Users

Members can administer local user accounts, share folders and
printers, and perform other limited administrative tasks on the local
computer.

Replicator

This special group supports file replication in a domain using DFS,
and it needs no members added to it.

Users

Members have the rights and permissions that are normally assigned to
ordinary users of the local computer or other rights and permissions
as they are specifically assigned.

Table 4-16 shows the initial membership of these
built-in local groups on a standalone server or client computer that
is part of a workgroup.

Domain Setting

In a domain setting, four types

of
built-in groups are available:

Built-in local groups

Built-in domain local groups

Built-in global groups

Built-in system groups

The first type exists in the Local Security Database of member
servers or client computers running WS2003 and is found within the

Groups folder of the Local Users and Groups node
under System Tools in Computer Management. The remaining three exist
within Active Directory on domain controllers and are found in the
Builtin and Users OUs of the Active Directory Users and Computers
console. Let's look at each of these types
separately.

Built-in Local Groups

Built-in local
groups are
found only on member servers or client computers in the domain; they
are used to control access to resources on the local computer on
which they exist and to grant users the rights to perform system
tasks on this computer. Essentially, they function the same way in a
domain-based network as they do in the workgroup setting described
earlier. The only difference is that when a standalone server or
client computer is moved from a workgroup to a domain, the membership
of its built-in local groups changes from what is shown in Table 4-16 to that shown in Table 4-17.
These changes give administrators, users, and guests in the domain
appropriate rights and permissions to the resources on the computer.

An example might help. When a standalone server running WS2003 and
belonging to a workgroup joins a domain (and hence becomes a member
server in that domain), the built-in global group Domain Admins
(which is defined in Active Directory on domain controllers in the
domain) becomes a member of the Administrators built-in local group
on the member server. In this fashion, any users that belong to the
Domain Admins global group also belong to the Administrators local
group on all member servers in the domain, giving them full
administrative rights and permissions on all member servers in the
domain. Built-in global groups are discussed later.

An additional built-in local group called Pre-Windows 2000 Compatible Access is created when you promote a member server to a domain controller. This group lets you choose between stronger WS2003 security and weaker security that might be needed to continue running legacy applications, particularly for compatibility with NT 4.0 RAS servers. If you have problems running legacy applications after promoting a server to a domain controller, add the special group Everyone to this group and reboot your domain controllers.

Built-in Domain Local Groups

When a member
server is promoted to a domain controller, the existing built-in
local groups on the machine are changed to built-in domain local
groups, and additional ones are created. Built-in domain local groups
have predefined rights and permissions on domain controllers to
simplify the task of administering domain controllers and the domain
in which they reside. They are used to control access to resources on
domain controllers and to grant users rights to perform system tasks
on these computers. The standard built-in domain local groups on a
WS2003 domain controller include:

Account Operators

Members can create, modify, and delete user accounts and groups on
domain controllers in the domain.

Administrators

Members can perform any administrative task on domain controllers in
the domain.

Backup Operators

Members can bypass file security to back up and restore any files on
any domain controllers in the domain.

Guests

Members have no rights or permissions on domain controllers in the
domain, unless they are specifically assigned.

Print Operators

Members can administer network printers on domain controllers in the
domain.

Replicator

This special built-in domain local group is used to implement file
replication in a domain and doesn't need any members
added to it.

Server Operators

Members can share folders and backup domain controllers in the domain.

Users

Members have the rights and permissions that are normally assigned to
ordinary users for domain controllers in the domain or other rights
and permissions as they are specifically assigned.

If the domain functional level of a domain is changed from Windows
2000 mixed to Windows 2000 native or Windows Server 2003, the
built-in domain local groups are sometimes just called security
groups. Additional built-in domain local groups may also be present,
depending on which optional WS2003 components are installed. The
following are optional built-in domain local groups.

DHCP Users

Members have read-only access to settings on a DHCP server.

DnsAdmins

Members can administer DNS servers.

RAS and IAS Servers

Members are servers that can access remote access properties of users.

WINS Users

Members have read-only access to WINS servers.

Table 4-18 shows the initial membership of the
standard built-in domain local groups on a member server that has
just been promoted to the role of domain controller.

Here's another example to make things clear. A
domain controller is configured as the print server for a network
printer. Sally needs to be granted the necessary rights and
permissions to manage the network printer. To do this, simply add
Sally's user account to the Print Operators group on
any domain controller in the domain.

Built-in Global Groups

Built-in global groups
on domain
controllers are used to group together domain users who have similar
resource access needs, making it easier to assign permissions to them
for shared network resources. Built-in global groups have no
predefined rights or permissions; you typically grant them rights and
permissions by making them members of domain local groups on domain
controllers or local groups on member servers.

The standard built-in global groups on a domain controller are:

Domain Admins

Members are users who need full administrative rights in the domain.

Domain Computers

Members are member servers and workstations in the domain.

Domain Controllers

Members are domain controllers in the domain.

Domain Guests

Members are users who require only temporary access to resources in
the domain.

Domain Users

Members are ordinary users in the domain.

Enterprise Admins

Members can administer any domain in the forest.

Additional built-in global groups may also be present, depending on
which optional WS2003 components are installed. These optional
built-in global groups include:

Cert Publishers

Members are enterprise certification and renewal agents.

DnsUpdateProxy

Members are DNS clients that are allowed to perform dynamic updates
on behalf of other clients (typically DHCP servers).

Group Policy Creator Owners

Members can modify Group Policy for the domain.

Schema Admins

Members can administer the Active Directory schema.

When the forest functional level is changed from Windows 2000 to Windows Server 2003, the scope of the Enterprise Admins and Schema Admins groups becomes universal instead of global. You could call these groups built-in universal groups if you like.

Table 4-19 shows the initial membership of the standard
built-in global groups.

Built-in System Groups

Built-in system groups (also called special identities)
exist on all computers running WS2003whether they belong to a
workgroup or a domain. You can't modify the
membership of a built-in system group. Instead, users temporarily
become members of different system groups, depending on the kind of
system or network activity in which they are involved. In other
words, it's not who you are but what you are doing
that determines whether you belong to one or more of the built-in
system groups on a computer.

For example, if you log on to the local computer using its keyboard
and try to access a folder on that computer, you are considered a
member of the Interactive system group as far as accessing that
resource is considered. If the Interactive group is explicitly denied
access to the folder, no one who logs on locally to the computer will
be able to access the folder (a rather extreme example).

System groups aren't displayed as groups in the
Local Users and Groups console or in the Active Directory Users and
Computers console, but they are displayed and can be selected when
you are configuring permissions on files and folders on NTFS volumes,
on printers, or on objects in Active Directory.

The following are some of the more important built-in system groups
on a WS2003 computer:

Authenticated Users

All users who have valid user accounts on the computer or domain (the
same as the Everyone group, except it doesn't
include anonymous users or guests)

Creator Owner

The user who owns the particular local or network resource under
consideration

Everyone

All network users, including users with valid user accounts on the
computer or domain, users from other domains (trusted or untrusted),
and guest users

Interactive

The user who is currently logged on locally at the keyboard of the
local computer and is accessing a resource on this computer

Network

All users who are currently logged on to computers on the network and
are accessing a resource on the local computer