Active Directory User and Computer Accounts

The Windows 2000 operating system uses a user or computer account to authenticate
the identity of the user or computer and to authorize or deny access to domain
resources. For example, users who are members of the Enterprise Administrators group
are, by default, granted permission to log on at any domain controller in the Active
Directory forest. Administrators can audit actions performed by user or computer
accounts.
You add, disable, reset, or delete user and computer accounts using the Active Directory
Users and Computers tool.
This section covers the following topics:
User Accounts
Computer Accounts
Security Principals
Group Policy Applied to User and Computer Accounts

User Accounts
A user requires an Active Directory user account to log on to a computer or to a domain.
The account establishes an identity for the user; the operating system then uses this
identity to authenticate the user and to grant him or her authorization to access specific
domain resources.
User accounts can also be used as service accounts for some applications. That is, a
service can be configured to log on (authenticate) as a user account, and it is then
granted access to specific network resources through that user account.
Predefined User Accounts
Windows 2000 provides the following two predefined user accounts 1:
Administrator account
Guest account
You can use these accounts to log on locally to a computer running Windows 2000 and to
access resources on the local computer. These accounts are designed primarily for initial
logon and configuration of a local computer. The Guest account is disabled and you must
enable it explicitly if you want to allow unrestricted access to the computer. The
Administrator account is the most powerful account because it is a member of the
Administrators group by default. This account must be protected with a strong password
to avoid the potential for security breach to the computer.
To enable the Windows 2000 user authentication and authorization features, you create
an individual user account for each user who will participate on your network. Then add
each user accountincluding the Administrator and Guest accountsto Window 2000
groups, and assign appropriate rights and permissions to each group.

Computer Accounts

Like user accounts, Windows 2000 computer accounts provide a means for
authenticating and auditing the computer's access to the network2 and its access to
domain resources. Each Windows 2000 computer to which you want to grant access to
resources must have a unique computer account.
Computers running Windows 98 and Windows 95 do not have the advanced security
features of those running Windows 2000 and Windows NT, and they cannot be assigned
computer accounts in Windows 2000 domains. However, you can log on to a network and
use Windows 98 and Windows 95 computers in Active Directory domains.

Security Principals
Active Directory user and computer accounts (as well as groups, covered later) are
referred to as security principals, a term that emphasizes the security that the operating
system implements for these entities. Security principals are directory objects that are

automatically assigned SIDs when they are created. Objects with SIDs can log on to the
network and can then access domain resources.
If you establish a trust relationship between a domain in your Windows 2000 forest and a
Windows 2000 domain external to your forest, you can grant security principals from the
external domain access to resources in your forest. To do so, add external security
principals to a Windows 2000 group, which causes Active Directory to create a "foreign
security principal" object for those security principals3. You can make foreign security
principals members of domain local groups (covered later). You cannot manually modify
foreign security principals, but you can see them in the Active Directory Users and
Computers interface by enabling Advanced Features.

Group Policy Applied to User and Computer Accounts

In the Windows 2000 operating system environment, you can associate Group Policy
configuration settings with three Active Directory containersorganizational units (OUs),
domains, or sites. Group Policy settings associated with a given container either affect all
users or computers in that container, or they affect specified sets of objects within that
container. You can use Group Policy to configure security options, manage applications,
manage desktop appearance, assign scripts, and redirect folders from local computers to
network locations. The system applies group policy to computers at boot time or to users
when they log on. (You can also set the group policy refresh interval policy for users or
computers; the default refresh interval for both users and computers is 90 minutes.)
Here are three examples of using group policy settings:
Set the minimum password length and the maximum length of time that a
password remains valid for an entire domain.
Assign logon and logoff scripts to the user accounts in each organizational unit.
Specify which applications are available to users when they log on.
For detailed information about Group Policy, see "For More Information."
Top of page

Active Directory Groups

Groups are Active Directory (or local computer) objects that can contain users, contacts,
computers, and other groups. In Windows 2000, groups are created in domains, using the
Active Directory Users and Computers tool. You can create groups in the root domain, in
any other domain in the forest, in any organizational unit, or in any Container class object
(such as the default Users container). Like user and computer accounts, groups are
Windows 2000 security principals; they are directory objects to which SIDs are assigned
at creation.
You can nest groups; that is, you can add a group as a member of another group
(according to specified rulessee the section "Mode Governs Nesting Options"). Nesting
groups makes it easier to manage users and can reduce network traffic caused by
replication of group membership changes.
Planning group strategies is an essential part of deploying Active Directory. Before you
create groups, determine the number of domains you will have on your network and
which of those domains (if any) are mixed-mode and which are native-mode:
Mixed-mode domain. The Windows 2000 operating system installs, by default,
in a mixed-mode network configuration. A mixed-mode domain is a networked set
of computers running both Windows NT 4.0 and Windows 2000 domain
controllers. (You can also have a mixed-mode domain running only Windows 2000
domain controllers.)
Native-mode domain. You can convert a domain to native mode when it
contains only Windows 2000 Server domain controllers.

Important: Do not change from mixed to native mode if you have, or will have, any
Windows NT 4.0 backup domain controllers (BDCs) in the domain. Changing a domain
from mixed mode to native mode is an irreversible operation.
Both mixed-mode and native-mode domains can contain Windows NT 4.0 member
servers and Windows NT and Windows 9.x clients.
The following sections discuss the structure of groups and how you can use the various
groups to help organize your network:
Group Type: Security or Distribution
Group Scope: Local, Domain Local, Global, or Universal
How Domain Mode Affects Groups
Windows 2000 Built-in, Predefined, and Special Groups

Group Type: Security or Distribution

Windows 2000 Server has two kinds of groups:
Distribution groups
Security groups
Although this section is primarily about the role groups play in security, distribution
groups are also briefly described to clarify the difference between the two group types.
The next two subsections describe the characteristics of security and distribution groups.
Distribution Groups
Distribution groups have only one functionto create e-mail distribution lists. You use
distribution groups with e-mail applications (such as Microsoft Exchange) to send e-mail
to the members of the group. As with a security group, you can add a contact to a
distribution group so that the contact receives e-mail sent to the group.
Distribution groups play no role in security (you do not assign permissions to distribution
groups), and you cannot use them to filter Group Policy settings.
Security Groups
In the Windows 2000 operating system, security groups are an essential component of
the relationship between users and security. Security groups have two functions:
To manage user and computer access to shared resources
To filter Group Policy settings
You collect users, computers, and other groups into a security group and then assign
appropriate permissions to specific resources (such as file shares and printers) to the
security group. This simplifies administration by letting you assign permissions once to
the group instead of multiple times to each individual user. When you add a user to an
existing group, the user automatically gains the rights and permissions already assigned
to that group.
Integral to understanding security groups is the concept of an access token. As explained
in the Introduction, an access token is an object containing the security information for a
logon session. Windows 2000 creates an access token when a user logs on, and every
process executed on behalf of the user has a copy of the token. (A process is software
that is currently running.) The token identifies the user, the security groups to which the
user belongs, and the privileges granted to the user and to the user's security groups.
The system uses the token to control access to securable objects and to control the
ability of the user to perform various system-related operations on the local computer.
If you use an e-mail client that can use Active Directory for address book lookup, or an email system that uses Active Directory as its directory (such as Exchange 2000), you can
also use security groups to send e-mail to all members of the group. You can add a
contact to a security group, and that contact is sent e-mail along with the other members
of the group. However, you cannot assign rights and permissions to a contact.

When implementing an administration strategy for security groups, keep the following
general guidelines in mind:
Small organizations. Some small organizations with a Windows 2000 nativemode forest will choose to use security groups with Universal scope to manage all
their group needs. For organizations that expect to grow, two alternative
strategies are available:
o Use Universal groups initially and then convert to the Global/Local pattern
(described next) recommended for medium to large organizations.
o Some growing small organizations will choose to implement the
Global/Local pattern used by larger organizations from the start. Because
groups with universal scope (and their members) are listed in the global
catalog database4, a large number of universal groupsespecially where
membership changes frequentlycan cause a lot of replication traffic. If
this is the situation, use the guidelines for medium to large organizations.
Medium to large organizations. Experience shows that using the approach
described below will help you achieve maximum flexibility, scalability, and ease of
administration when managing security groups. Using Account (global) groups
and Resource (local) groups in the way described here lets you use groups to
mirror your organization's functional structure.
o Put users into security groups with global scope. A global group can usually
be thought of as an Accounts group, that is, a group that contains user
accounts.
o Put resources into security groups with domain local (or machine local)
scope. A local group can usually be thought of as a Resource group, that is,
a group to which you assign permissions to access a resource.
o Put a global group into any domain local (or machine local) group in the
forest (this is especially efficient when more than one domain is involved).
o Assign permissions for accessing resources to the domain local (or
machine local) groups that contain them.
o Delegate administration of groups to the appropriate manager or group
leader.
Understanding what these guidelines mean requires understanding the different kinds of
group scope, explained in the next section.

Types of Scope
Universal
Universal groups can be used anywhere in the same Windows forest. They
are only available in a Native-mode enterprise. Universal groups may be an
easier approach for some administrators because there are no intrinsic
limitations on their use. Users can be directly assigned to Universal groups,
they can be nested, and they can be used directly with access-control lists to
denote access permissions in any domain in the enterprise.
Universal groups are stored in the global catalog (GC); this means that all
changes made to these groups engender replication to all global catalog
servers in the entire enterprise. Changes to universal groups must therefore
be made only after a careful examination of the benefits of universal groups

as compared to the cost of the increased global catalog replication load. If an

organization has but a single, well-connected LAN, no performance
degradation should be experienced, while widely dispersed sites might
experience a significant impact. Typically, organizations using WANs should
use Universal groups only for relatively static groups in which memberships
change rarely.

Global
Global groups are the primary scope of groups into which users are placed in
Mixed-mode domains. Global groups can be placed only in the security
descriptors of resource objects that reside in the same domain. This means
that you cannot restrict access to an object based solely on user membership
in a global group from another domain.
Global group membership for a user is evaluated when that user logs on to a
domain. Because global group membership is domain-centric, changes in
global group membership do not impose global catalog replication throughout
an entire enterprise.
In a Native-mode domain, global groups can be nested within each other. This
may be useful when administrators have nested organizational units, and
want to delegate Organizational Unit (OU) administrative functionality in a
gracefully decreasing manner down an OU tree. In this situation, a global
group tree can be used as a parallel construct, for the assignment of such
decreasing privileges

Domain Local
Domain Local groups can be used for the direct assignment of access policies
on specific resources that are not directly stored in Active Directory, (such as
file server shares, printer queues, and so on).
Domain Local groups should not be used to assign permissions on Active
Directory objects, because Domain Local groups cannot be evaluated in other
domains, and parts of most Active Directory objects get replicated to other
domains in the form of the GC. Access restrictions placed on Active Directory
objects that are based on Domain Local group membership have no effect on
GC queries that take place in groups other than the domain in which the
Domain Local group originated.

Groups on Standalone Servers and Windows 2000 Professional