Active Directory Users, Computers, and Groups

Operating System

Abstract

In the Microsoft® Windows® 2000 operating system, the Active Directory™ service provides user and computer accounts and distribution and security groups. The operating system integrates user, computer, and group security with the Windows 2000 security subsystem as a whole. This paper introduces administrators unfamiliar with Windows 2000 to the way users, computers, and groups are organized and how user authentication and authorization are used to provide security.

On This Page

Introduction Active Directory User and Computer Accounts Active Directory Groups User Authentication User Authorization Summary Appendix A: Built-in, Predefined, and Special Groups Appendix B: User Rights

Introduction

A great part of network administration involves management of users, computers, and groups. A successful operating system must ensure that only properly authenticated users and computers can logon to the network and that each network resource is available only to authorized users. In the Microsoft® Windows® 2000 operating system, the Active Directory™ service plays several major roles in providing security. Among these roles are the efficient and effective management of user logon authentication and user authorization. Both are central features of the Windows 2000 security subsystem and both are fully integrated with Active Directory.

Active Directory user authentication confirms the identity of any user trying to log on to a domain and lets users access resources (such as data, applications, or printers) located anywhere on the network. A key feature of Windows 2000 user authentication is its single sign-on capability, which makes multiple applications and services available to the user over the network without the user having to provide credentials more than once.

Active Directory user authorization secures resources from unauthorized access. After a user account has received authentication and can potentially access an object, the type of access actually granted is determined by what user rights are assigned to the user and which access control permissions are attached to the objects the user wishes to access. An object is a distinct, named set of attributes, and includes shared resources such as servers, shared volumes, and printers; network user and computer accounts; as well as domains, applications, services, and security policies.

This paper describes Windows 2000 users, computers, and groups from the perspective of security, with an emphasis on the security issues of authentication and authorization. The following sections cover these topics:

  • Active Directory User and Computer Accounts

  • Active Directory Groups

  • User Authentication

  • User Authorization

For security topics not covered in this paper and for information about the structure of Active Directory (including Active Directory objects, domains, trees, forests, trusts, organizational units, and sites), see the section "For More Information" at the end of this document.

Concepts

The following definitions will help you understand the basic concepts that are used throughout the paper:

  • User rights are assigned to groups (or users). User rights include both privileges (such as Back Up Files and Directories) and logon rights (such as Access this Computer from Network).

  • Access control permissions (such as Read, Write, Full Control, or No Access) are attached to Windows 2000 objects. In the case of Active Directory objects, access control can be defined not only for each object in the directory but also for each property of each object. (For a list of all object types, see the section "Object Types, Managers, and Tools.")

  • Access token. Each time a user logs on, Windows 2000 creates an access token. The access token is a representation of the user account and contains the following elements:

    • Individual SID. Security identifier (SID) representing the logged-on user

    • Group SIDs. SIDs representing the logged-on user's group memberships

    • User Rights. Privileges (associated with each SID) granted to the user or to groups to which the user belongs

  • When the user tries to access an object, Windows 2000 compares each SID in the user's access token to entries in an object's discretionary access control list (DACL) to determine whether the user has permission to access the object and, if access is allowed, what type of access it is. In some cases, user rights in the user's token may override the permissions listed in the DACL and access may be granted that way.

  • An access token is not updated until the next logon, which means that if you add a user to a group, the user must log off and log on before the access token is updated.

  • Security identifier (SID). A SID is a code that uniquely identifies a specific user, group, or computer to the Windows 2000 security system. A user's own SID is always attached to the user's access token. When a user is made a member of a group, the SID for that group is also attached to the user's access token.

  • Access Control List (ACL). Each Active Directory object (as well as each file, registry key, and so on) has two associated ACLs:

    • DACL. The discretionary access control list (DACL) is a list of user accounts, groups, and computers that are allowed (or denied) access to the object.

    • SACL. The System Access Control List (SACL) defines which events (such as file access) are audited for a user or group.

  • Access Control Entry (ACE). A DACL or SACL consists of a list of Access Control Entries (ACEs), where each ACE lists the permissions granted or denied to the users, groups, or computers listed in the DACL or SACL. An ACE contains a SID with a permission, such as Read access or Write access. Windows 2000 combines access permissions—if you have Read access to an object because you are a member of Group A and if you have Write access because you are a member of Group B, you have both Read and Write access to the object. However, if you have No Access as a member of Group C, you will not have access to the object.

    Figure 1 shows how a user's access token and an object's DACL let the user (in this case) access the object. When the user, Adam, requests access to the payroll file object, Windows 2000 compares each SID in Adam's access token to each ACE in the DACL to see if access is explicitly denied to Adam or to any group to which Adam belongs. It then checks to see if the requested access is specifically permitted. Windows repeats these steps until it encounters a No Access or until it has collected all the necessary permissions to grant the requested access. If the DACL does not specifically allow permission for each requested access, access is denied.

Bb727067.aduser01(en-us,TechNet.10).gif

Figure 1: User authentication creates an access token for the user. The access token contains the user's primary SID, together with the SIDs of any groups to which the user belongs. This user is authorized to access this domain resource, a payroll file.

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 accounts1:

  • 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 account—including the Administrator and Guest accounts—to 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 containers—organizational 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."

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 rules—see 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

  • Groups on Standalone Servers and Windows 2000 Professional

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 function—to 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 e-mail 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 native-mode 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:

    • Use Universal groups initially and then convert to the Global/Local pattern (described next) recommended for medium to large organizations.

    • 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 groups—especially where membership changes frequently—can 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.

    • 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.

    • 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.

    • 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).

    • Assign permissions for accessing resources to the domain local (or machine local) groups that contain them.

    • 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.

Group Scope: Local, Domain Local, Global, or Universal

Both types of group—security and distribution—can have one of three scopes (four when you include local groups, which exist in Windows 2000 to provide backward compatibility with Windows NT groups). A group's scope determines the extent to which the group can be nested in other groups or referenced in DACLs on resources in the Active Directory domain or forest.

Important: In the following discussion of group scope, remember that you assign permissions only to security groups (not to distribution groups).

By default, when you create a new group, it is configured as a security group with global scope (in both mixed-mode and native-mode domains).

If you have multiple forests, you can place groups (or users—but, typically, you should put users only into global groups) from any trusted domain into a local or domain local group. You can establish trust between any two domains in any two forests.

The four possible Windows 2000 group scopes are:

  • Groups with local scope (also called local groups)

  • Groups with domain local scope (also called domain local groups)

  • Groups with global scope (also called global groups)

  • Groups with universal scope (also called universal groups)

With some minor differences, domain local and global groups exist in the Windows NT operating system (where they are called local groups and global groups). Universal groups are new in Windows 2000. The following subsections describe each type of group scope.

Groups with Local Scope

The local groups used in both Windows NT and Windows 2000 are precursors of and are in some ways similar to the domain local groups (described next) introduced in Windows 2000. Local groups are sometimes referred to as machine local groups to contrast them with domain local groups. Local groups have the following features:

  • Mode. Local groups are the only type of local group available in a Windows 2000 mixed-mode domain. In the case of Windows 2000 native-mode domains, only Built-in groups have local scope.

  • Membership. Local groups can have members from anywhere in the forest, from trusted domains in other forests, and from trusted down-level domains.

  • Permissions. A local group has only machine-wide scope; that is, it can be used to grant resource permissions only on the machine on which it exists. (Note, however, that local groups created on a domain controller are available on every domain controller in that domain and can be used to grant resource permissions on any domain controller in that domain.)

Groups with Domain Local Scope

Domain local groups, a new feature of the Windows 2000 operating system, have the following features:

  • Mode. Domain local groups are available only in native-mode (but not mixed-mode) domains.

  • Membership. Like local groups, domain local groups can have members from anywhere in the forest, from trusted domains in other forests, and from trusted down-level domains.

  • Permissions. A domain local group has domain-wide scope; that is, it can be used to grant resource permissions on any Windows 2000 machine within the domain in which it exists (but not beyond its domain).

Using Domain Local Groups

Groups with domain local scope are designed to be used in DACLs on a domain's resources. That is, domain local groups help you define and manage access to resources within a single domain.

For example, to give five users access to a particular printer, you could add all five user accounts, one at a time, to the printer permissions list. Later, if you wanted to give the same five users access to a new printer, you would again have to specify all five accounts in the permissions list for the new printer. Or, you could take advantage of groups with domain local scope. To do so, perform the following steps:

  1. Create a group with domain local scope, and assign it permission to access the printer (this is the Resource group).

  2. Put the five user accounts into a group with global scope (this is the Accounts group), and add this global group to the group having domain local scope. (Global groups are described in the next subsection.)

Now, when you want to give another five users access to this printer, you can simply add them to the global group that is a member of the domain local group which has permission to access the printer, and you are done. Doing so gives all five new members of the group access to the printer in one step. Using domain local groups in this way provides the following benefits:

  • Membership of the domain local group is controlled by the administrator(s) where the resource (the printer) is located, not where the users are—which makes it in line with how administration is typically done.

  • Because a domain local group is associated with an access token built when a member of that group authenticates to a resource in that domain, unnecessary network traffic (carrying of membership information) is avoided. (If, instead, you assigned a global group permission to access the printer, the global group can end up in a user's token anywhere in the forest, causing unnecessary network traffic.)

Groups with Global Scope

Global groups, effectively the same as Windows NT global groups, have the following features:

  • Mode. Global groups exist in both mixed-mode and native-mode domains.

  • Membership. Global groups can have members from within their own domain (only).

  • Permissions. Although a global group is limited to domain-wide scope as far as membership goes, it can be made a member of machine or domain local groups or granted permissions in any domain (including trusting domains in other forests and down-level domains with which a trust relationship exists). That is, groups with global scope can be put into other groups in any trusting domain.

Using Global Groups

Groups with global scope help you manage directory objects that require daily maintenance, such as user and computer accounts.

Use global groups to collect users or computers that are in the same domain and share the same job, organizational role, or function. For example, "Full-time employees," "Managers," "RAS Servers" are all possible global groups. Because group members typically need to access the same resources, make these global groups members of domain local or machine local groups, which, in turn, are listed on the DACL of needed resources. Membership of these groups can be efficiently managed by administrators of user domains, because these administrators are familiar with the functions and roles played by users and computers in their domain.

Groups with Universal Scope

Universal groups, a new feature of the Windows 2000 operating system, have the following features:

  • Mode. Universal groups are available only in native-mode domains.

  • Membership. Universal groups can have members from any Windows 2000 domain in the forest. (Universal groups can contain members from mixed-mode domains in the same forest, but this is not recommended. Members from such domains cannot have the universal group's SID added to their access token because universal groups are not available in mixed-mode domains. Therefore, troubleshooting access problems would be difficult.)

  • Permissions. Universal groups can be granted permissions in any domain, including in domains in other forests with which a trust relationship exists.

Using Universal Groups

A small organization can use universal groups to implement a relatively simple group structure. If you choose to use groups with universal scope in a multi-domain environment, these groups can help you represent and consolidate groups that span domains. For example, you might use universal groups to build groups that perform a common function across an enterprise.

Although few organizations will choose to implement this level of complexity, you can add user accounts to groups with global scope, nest these groups within groups having universal scope, and then make the universal group a member of a domain local (or machine local) group that has access permissions to resources. Using this strategy, any membership changes in the groups having global scope do not affect the groups with universal scope.

A useful guideline is to designate widely used groups that seldom change as universal groups. The reasons for this approach are explained next.

Group Scope and Replication Traffic

Groups having universal scope—and all of their members—are listed in the global catalog. Whenever one member of a group with universal scope changes, the entire group membership must be replicated to all global catalogs in the domain tree or forest. Therefore, if you use groups with universal scope, use them in situations where the membership of the group does not change frequently.

Groups having global or domain local scope are also listed in the global catalog, but their individual members are not listed. Using these groups thus reduces the size of the global catalog and reduces the replication traffic needed to keep the global catalog up-to-date. Therefore, use groups with global or domain local scope if the group membership changes frequently.

How Domain Mode Affects Groups

As explained above, a mixed-mode domain typically has one or more Windows NT Server 4.0 domain controllers in addition to Windows 2000 domain controllers, although it can have only Windows 2000 domain controllers. A native-mode domain can have only Windows 2000 Server domain controllers. Both mixed-mode and native-mode domains can include Windows NT 4.0 member servers and Windows NT and Windows 9.x clients.

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.

Mode Determines Whether You Can Convert Group Types

In a native-mode domain, you can convert a security group to a distribution group and vice versa. You cannot convert either group to the other in a mixed-mode domain. A Windows NT domain controller cannot handle group type conversion because it sees only security-enabled groups.

Mode Affects Security and Distribution Groups Differently

Distribution groups are not affected by mode because distribution group membership is not enumerated at logon. If a process needs to know the composition of the group, it has to ask an Active Directory server, which, by definition, is a Windows 2000 domain controller.

Whether a domain is native or mixed mode does affect the behavior of security groups. When a user logs on to a domain account, the user's security group membership is resolved on the domain controller that handles the logon. In mixed mode, if a Windows NT 4.0 domain controller handles the logon, then it must be able to enumerate the members of the security groups to which the user belongs. Thus, the behavior of security groups in a Windows 2000 domain running in mixed mode must match the behavior of security groups in Windows NT 4.0.

Mode Governs Nesting Options

Updates to the Active Directory store must be made in a single transaction. One consequence of this is that you should not create groups with more than 5,000 members. Because group memberships are stored in a single multi-valued attribute, a change to the membership requires that the whole attribute—that is, the whole membership list—be updated in a single transaction. Microsoft has tested and supports group memberships of up to 5,000 members.

Windows 2000 lets you get around this limitation by nesting groups to increase the effective number of members. Nesting also lessens the amount of network traffic caused by replication of group membership changes.

Available nesting options depend on whether the domain is in native mode or mixed mode. The following list describes what can be contained in a group that exists in a native mode domain:

  • Groups with universal scope can contain user accounts, computer accounts, other universal groups, and global groups from any trusted domain.

  • Groups with global scope can contain user accounts from the same domain and other global groups from the same domain.

  • Groups with domain local scope can contain user accounts, universal groups, and global groups from any trusted domain. They can also contain other domain local groups from within the same domain. (Typically, put user accounts into global groups, not into domain local groups, then put the global groups into domain local groups, and then assign access permissions to resources to the local groups.)

Security groups in a mixed-mode domain can contain only the following:

  • Local groups can contain global groups and user accounts from trusted domains. (It is not recommended to put users directly into local groups; instead, put users into global groups, put global groups into local groups, and then assign permissions to the local groups).

  • Global groups can contain only user accounts.

Changing to Native Mode Impacts Groups

When a Windows NT primary domain controller (PDC) is upgraded to Windows 2000 Active Directory, Windows NT local groups become Windows 2000 local groups and Windows NT global groups become Windows 2000 global groups. When a domain is converted to native mode, local groups become domain local groups.

When a user is authenticated, an access token is created for the user containing his or her primary SID, together with the SIDs of any groups he or she belongs to. At the time the domain is switched to native mode, because domain local groups have domain-wide scope, the SIDs of any domain local groups of which the user is a member are now added to the user's access token.

Windows 2000 Built-in, Predefined, and Special Groups

Windows 2000 provides three sets of default groups: Built-in, Predefined, and Special groups. These default groups are summarized in "Appendix A: Built-in, Predefined, and Special Groups".

Groups on Standalone Servers and Windows 2000 Professional

Universal groups, group nesting, and the distinction between security and distribution groups are available only on Active Directory domain controllers and Windows 2000 member servers. Group accounts on Windows 2000 Server stand-alone servers and on Windows 2000 Professional function as in Windows NT 4.0:

  • The only groups you can create locally on a stand-alone server or Professional workstation are local groups.

  • A local group created on a stand-alone server or Professional workstation can be assigned permissions only on that computer.

However, if you join a Windows 2000 Professional computer to a Windows 2000 domain, the workstation can display global groups and universal groups both from that domain and from all domains in the forest. You can assign permissions for the local computer to these groups or place them in the local computer groups.

User Authentication

User authentication confirms the identity of any user trying to log on to a domain or access network resources. Windows 2000 authentication enables single sign-on to all network resources. A user can log on to the domain once, using a single password or smart card, and can then access resources on any computer in the domain. For users, single sign-on provides quick and efficient access to resources. For administrators, single sign-on reduces the amount of support required for users because the administrator needs to manage only one account per user.

Windows 2000 user authentication, including single sign-on, is implemented as a single, two-part process: interactive logon and network authentication. Successful user authentication depends on both parts of this process. The first two subsections briefly describe these two aspects of authentication. The third subsection describes authenticating external users:

  • Interactive logon

  • Network authentication

  • Using certificates to authenticate external users

For detailed technical descriptions of Windows 2000 user authentication, see the Windows 2000 Resource Kit "Authentication" chapter listed in "For More Information."

Interactive Logon

Interactive logon (the first part of the single sign-on process) confirms the user's identity to the user's Active Directory domain account or local computer. When a user walks up to the computer to start work, the user logs on, that is, presents credentials (domain or local) to the computer to gain access to its resources (monitor, keyboard, mouse, local disk, network access, and so on). This process differs depending on the type of user account:

  • Domain account. With a domain account, a user logs on to the network (with a password or smart card) using single sign-on credentials stored in Active Directory. After logging on with a domain account, an authorized user can access resources in the domain and any trusting domains.

    • If a password is used to log on to a Windows 2000 computer using a domain account in a Windows 2000 domain, Windows 2000 uses Kerberos version 5 (V5) for authentication. If a smart card is used instead of a password, Windows 2000 uses Kerberos V5 authentication with certificates.

    • If the authenticating domain controller is a Windows NT 4.0 domain controller or if the user's computer is a Windows NT 4.0 computer, then the authentication used is Windows NT LAN Manager (NTLM). (See next section for more about Kerberos and NTLM.)

  • Local account. With a local computer account, a user logs on to a local computer using credentials stored in that computer's Security Accounts Manager5(SAM), which is the Windows 2000 local security account database. Any Windows 2000 computer that is not a domain controller can store local user accounts, but those accounts can be used for access only to that local computer.

Network authentication (described next) is transparent to users using a domain account. When using the domain account, the user's credentials are used for a single sign-on. Users using a local computer account, however, must provide credentials (such as a user name and password) each time they access a network resource.

Network Authentication

Network authentication (the second part of the single sign-on process) confirms the user's identity to any network service the user attempts to access. For network authentication, Windows 2000 uses one of the following industry-standard types of authentication:

  • Kerberos V5 authentication. Kerberos V5, the default method of network authentication for services for computers running Windows 2000 server or client software, is the primary security protocol for authentication within Windows 2000 domains. Based on Internet standard security, Kerberos V5 authentication is used with either a password or a smart card for interactive logon. Kerberos provides fast, single logon to Windows 2000 Server-based resources, as well as to other environments that support this protocol.

    The Kerberos V5 protocol verifies both the identity of users and of network services. This dual verification, called mutual authentication, takes place between a client and server—the server verifies the client identity, and the client verifies the server's identity. Kerberos replaces NTLM (see next subsection) as the primary security protocol for access to resources within or across Windows 2000 Server domains. If any computer involved in a transaction does not support Kerberos V5, the system uses the NTLM protocol.

    The Kerberos V5 authentication mechanism issues tickets for accessing network services. A ticket, issued by a domain controller, is a set of identification data for authenticating a security principle. Tickets contain encrypted data (including an encrypted password) that confirms the user's identity to the requested service. Except for entering a password or smart card credentials, the Kerberos authentication process is invisible to the user. For a detailed technical description of Windows 2000 and Kerberos (and for some information about NTLM), see the link to the "Windows 2000 Kerberos Authentication" white paper listed in "For More Information."

  • Windows NT LAN Manager (NTLM) authentication. NTLM authentication also provides network authentication within Windows 2000 domains. In Windows 2000, NTLM is used as the authentication protocol for transactions between two computers in a domain, where one or both computers is running Windows NT 4.0 or earlier. (Recall that by default, Windows 2000 is installed in a mixed-mode network configuration—that is, a configuration that uses any combination of Windows NT 4.0 and Windows 2000.) NTLM is used when either the client or server uses an earlier version of Windows. That is, computers with Windows 3.x, Windows 95/98, as well as Windows NT Workstation 4.0 use the NTLM protocol for authentication in Windows 2000 domains. NTLM is also the authentication protocol for computers not participating in a domain, such as standalone servers and workgroups.

  • Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication. SSL/TLS provides authentication when a user attempts to access a secure Web server. SSL/TLS consists of four operations:

    • Handshake and cipher suite negotiations. Client and server contact each other and choose a common cipher suite. The suite includes a method for exchanging the shared secret key; a method for encrypting data; and a Message Authentication Code (MAC) specifying how application data will be hashed and signed to prove integrity.

    • User identity authentication. The server always authenticates its identity to the client. However, whether the client needs to authenticate with the server depends on the application. The exact authentication method (primarily, which digital certificate format will be used) depends on the negotiated cipher suite.

    • Key exchange. After choosing a cipher suite, the client and server exchange a key, or the precursors with which to create a key, that they will use for data encrypting (again, depending on the negotiated cipher suite's requirements).

    • Application data exchange. The client application and the server application communicate with each other. All data is encrypted using the negotiated bulk encryption method.

Using Certificates to Authenticate External Users

Organizations must often support authentication of external users, individuals who do not have an account in Active Directory. Examples of when you may want to provide external users with secure access to specific data within the enterprise include corporate partners who need extranet access, a department that needs access to another department's intranet pages, or part of the public to whom you may want to provide selective access.

Active Directory supports external user authentication. To authenticate external users, you must do the following:

  • Use a certificate. The external user must have a certificate. A certificate is a file used for authentication and secure exchange of data on nonsecured networks, such as the Internet. A certificate securely binds a public key to the entity that holds the corresponding private key held by the individual. Certificates are digitally signed by the issuing certification authority (CA) and can be managed for a user, a computer, or a service.

    The external user's certificate must be issued by a CA that is listed in the certificate trust list for (or trusted by) the Active Directory site, domain, or organizational unit in which you have created the user account.

  • Create a user account. You must establish a user account (for use by one or more external users).

  • Map the certificate to the account. You must create a name mapping between the external user certificate and the Active Directory account you have created for authenticated access.

Any external user whose client program presents a mapped certificate can then access the permitted locations published on the appropriate Web site for your organization. The authentication process is transparent to the external user.

User Authorization

Besides confirming the identity of anyone attempting to access the network (user authentication, described in the preceding section), a good security system also protects specific resources—such as payroll data—from access by inappropriate users.

Active Directory secures resources from unauthorized access. From the standpoint of the user, controlling access to resources, or objects, on the network is called user authorization. From the standpoint of the object being protected, it is called object-based access control. Once a user account has received authentication and can potentially access an object, the type of access granted is determined by either the user rights that are assigned to the group (or user) or the access control permissions that are attached to the object.

This section covers these topics in the following subsections:

  • User rights: Assigned to groups

  • Access control permissions: Attached to objects

User Rights: Assigned to Groups

As an administrator, you can assign specific user rights to group accounts or to individual user accounts. You can think of them as user or group rights, rather than as simply user rights, because typically you assign rights to a group rather than to an individual user. There are two types of user rights:

  • Privileges. For example, the right to back up files and directories.

  • Logon rights. For example, the right to logon locally.

Note: Strictly speaking, logon rights, which refer to the local computer, do not belong in a discussion of Active Directory. They are included here briefly for clarity, because they are one type of user right. The other type of user right (privileges) can override permissions assigned to Active Directory objects and are thus integral to this discussion.

User rights are different from permissions (described next) because user rights apply to user accounts, whereas permissions are attached to objects.

Although user rights can apply to individual user accounts, to simplify the task of account administration user rights are best administered on a group account basis. It is easier to assign the set of user rights once to the group, rather than repeatedly assigning the same set of user rights to each individual user account. To remove rights from a user, you remove the user from the group.

Certain privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.

For a complete list of user rights (both privileges and logon rights), see "Appendix B: User Rights."

Access Control Permissions: Attached to Objects

Access control is the process of assigning permissions to access Active Directory objects.

You can assign permissions for objects to the following:

  • Groups, users, and special identities in the domain

  • Groups and users in that domain and any trusted domains

  • Local groups and users on the computer where the object resides

Understanding access control permissions requires understanding the following interrelated concepts:

  • Security descriptors

  • Object ownership

  • Object auditing

  • Object permissions and inheritance

Each of these topics is covered in the next subsections.

Security Descriptors

Windows 2000 implements access control by allowing administrators or owners of objects to assign security descriptors to objects stored in Active Directory (or to other types of objects). A security descriptor is a set of information attached to an object (such as a file, printer, or service) that specifies the permissions granted to different groups (or users), as well as the security events to be audited. For example, for the file temp.dat, you might grant Read, Write, and Delete permissions to the Administrators group, but assign only Read and Write permissions to the Operators group.

For Active Directory objects, in addition to controlling access to a specific object, you can also control access to a specific attribute of that object. For example, you can grant a user access to a subset of information, such as employees' names and phone numbers, but not grant access to the employees' home addresses.

Each security descriptor for an object in Windows 2000 contains four security components:

  • Owner. By default, the owner is the creator of the object, except for objects created by an administrator, in which case "Administrators" is the owner.

  • Discretionary Access Control List (DACL). As explained in the Introduction, the DACL (often referred to as ACL) is a list of specific groups, user accounts, and computers that are allowed or denied access to an object. To change a DACL, a permission called WRITE_DAC is required.

  • System Access Control List (SACL). As explained in the introduction, the SACL specifies which events are to be audited for which user or group. Examples of events you can audit are file access, logon attempts, and system shutdowns. To read or change the SACL, the SeSecurityPrivilege is required.

  • Group (for POSIX). The Group component is for POSIX compliance and is associated with the "primary group" set in individual user objects in User Manager. (POSIX is based on the UNIX operating system, but it can be implemented by other operating systems.)

Each assignment of permissions to a group (or user) is known as a permission entry or access control entry (ACE). An ACE is an entry in an access control list (DACL or SACL). The entry contains a SID and a set of access rights. A process (running on behalf of a user) with the user's access token that has a matching security ID is either allowed access rights, denied rights, or allowed rights with auditing. The entire set of permission entries in a security descriptor is known as a permission set. Thus, for the file temp.dat in the example above, the permission set includes two permission entries: one for the Administrators group and one for the Operators group.

Because the Active Directory security model associates a DACL and SACL with each of its containers, objects, and object attributes, administrators can protect their network from intentional hostile acts by attackers and inadvertent mistakes by users.

Permissions can be applied to any object in Active Directory or on a local computer, but, for simplicity of administration, it is important to understand that the majority of permissions should be applied to groups, rather than to individual users.

Object Ownership

Every Active Directory object has an owner. Windows 2000 assigns an owner to an object when the object is created. By default, the owner is the creator of the object. The owner controls how permissions are set for that object and to whom permissions are granted; that is, the object's owner implicitly has the WRITE_DAC permission.

Administrators create and own most objects in Active Directory and on network servers (when installing programs on the server). Users create and own data files in their home directories, and some data files on network servers. Users may also own objects that they have been allowed to create by way of delegation of administration; for example, users may own computer objects that they join to the domain.

Object ownership can be transferred in the following ways:

  • The current owner can grant the Take Ownership permission to other users, allowing those users to take ownership at any time.

  • An administrator can take ownership of any object under his or her administrative control by using the Take Ownership privilege that administrators possess on computers they control. For example, if an employee leaves the company, the administrator can take control of the employee's files.

Object Auditing

Windows 2000 lets you audit users' attempts to access specific objects in Active Directory. You can then view these security-related events in the security log with the Event Viewer.

Object Permissions and Inheritance

Object permissions, also called access rights, define the type of access granted to a group (or user) for an object or object property. The permissions you can attach to an object vary with the type of object. The following permissions, however, are common to all types of objects:

  • Read permissions

  • Modify permissions

  • Change owner

  • Delete

Two types of permissions exist:

  • Explicit permissions. Explicit permissions are attached directly to an object, either when the object is created, or by user action. For example, if you create a folder called Programs, the permissions attached to this folder are explicit permissions.

  • Inherited permissions. Inherited permissions are propagated to an object from a parent object. Inherited permissions ensure consistency of permissions among all objects within a given container, which eases the task of managing permissions. By default, objects within a container inherit the permissions from that container when the objects are created. For example, after you create the Programs folder, all subfolders and files subsequently created within the Programs folder automatically inherit the permissions from that folder. Thus, the Programs folder has explicit permissions, while all subfolders and files within it have inherited permissions.

In addition, to provide more precise access control, two types of granularity exist:

  • Object-type permissions. Object-type permissions define the types of objects (for example, an Active Directory object or a printer object) that a user or group is allowed to create or delete.

  • Per-property permissions. For Active Directory objects, Windows 2000 also supports per-property permissions. You can control not only who can see an Active Directory object, but also who has, for example, Read or Write access to specific object properties. Permissions for a single property are the finest level of granularity you can set.

Object Types, Managers, and Tools

Each type of object is controlled by an object manager and is managed using a specific tool. For example, to change the permissions on an Active Directory object, you use the Active Directory Users and Computers tool. The following table shows each type of object, its object manager, and its management tool:

Object Type

Object Manager

Management Tool

Active Directory objects

Active Directory

Active Directory Users and Computers

Files and folders

NTFS

Windows Explorer

Shares

Server service

Windows Explorer

Printers

Print spooler

Start menu, then select Settings, then Printers

Services

Service controllers

Security Templates, Security Configuration and Analysis

Registry keys

The registry

regedit32 command

A non-Active Directory object can also be represented by an Active Directory object by publishing it in the Active Directory. For example, you can publish a print queue in Active Directory and give only a certain group of users permission to find the queue in the directory. However, the DACL on the print queue object in Active Directory controls only who can read/write the print queue object in the directory; it does not imply anything about access to the actual print queue resource on the print server.

(For more about object publishing, see the link to "Active Directory Architecture" in "For More Information".)

Summary

Active Directory works with the Windows 2000 security subsystem to ensure that only authenticated users and computers can log on to the network and that each network resource is available only to authorized users or groups.

The Windows 2000 operating system automatically assigns SIDs to Active Directory security principals—user and computer accounts as well as groups—when they are created. Objects with SIDs can log on to the network and can be given or denied access to domain resources.

Active Directory groups can contain users, contacts, computers, and other groups. Before you create groups, you must first determine the number of domains you will have on your network and which of those domains are native-mode and which (if any) are mixed-mode.

Windows 2000 has two group types. You use security groups to manage user, group, and computer access to shared resources and to filter Group Policy settings. You use distribution groups to create e-mail distribution lists.

Both security and distribution groups can have either local, domain local, global, or universal scope. Each kind of scope differs in mode, membership, and permissions. You can make use of this flexibility to build a group structure that fits the size and organizational requirements of your business.

Windows 2000 user authentication is implemented as a two-part process: interactive logon, which confirms the user's identity to the domain or to the local computer, and network authentication, which confirms the user's identity to a network service when the user attempts to access it. Windows 2000 interactive logon provides the user access to multiple applications and services with a single sign-on, and its network authentication supports multiple authentication protocols.

After a user account is authenticated, the type of access granted to the user to specific network objects is determined by user rights, which are assigned to group (or user) accounts, and access control permissions, which are attached to objects. Together, user authentication and user authorization provide a strong, easy to administer security system for your network.

For More Information

For the latest information on Windows 2000 Server and Active Directory, check out the web site at https://www.microsoft.com/windows2000/technologies/directory/ad/default.asp.

In addition, you can look at the following links for more information:

Active Directory Architecture white paper— Active Directory structure, including objects, domains, trees, forests, trusts, organizational units, and sites.

Secure Networking Using Windows 2000 Distributed Security Services white paper—Integration of Active Directory and Windows 2000 distributed security.

Microsoft Security Advisor Website—Security information.

Windows 2000 Group Policy white paper—Details of Windows 2000 group policy.

Windows 2000 Kerberos Authentication white paper—Information about Kerberos (and some about NTLM).

See also the "Authentication," "Access Control," and "User Rights" chapters in Windows 2000 Resource Kit. The Windows 2000 Resource Kit is scheduled to be published by Microsoft Press in the first half of the year 2000. The Resource Kit is also located on the Windows 2000 Server and Advanced Server CDs as part of Support Tools.

Appendix A: Built-in, Predefined, and Special Groups

Windows 2000 provides the following types of default groups:

Name

Scope

Located In

Purpose

Built-in groups:
Account Operators
Administrators
Backup Operators
Guests
Print Operators
Replicator
Server Operators
Users

Domain local

Active Directory Users & Computers tool's Built-in folder

You use built-in groups to assign default sets of permissions to users who you want to have all or partial administrative control in that domain. For example, Backup Operations can back up and restore files & folders.

Predefined groups:
Group name
Cert Publishers
Domain Admins
Domain Computers
Domain Controllers
Domain Guests
Domain users
Enterprise Admins
Group Policy Admins
Schema Admins

Global

Active Directory Users & Computers tool's Users folder

You use predefined groups to collect users in this domain into Global groups, and then you place the Global group into Domain local groups in this and other domains. For example, because all users are automatically added to the Domain Users group, you can either assign permissions to a printer to the Domain users group or you can put the Domain Users group into a Domain local group that has permissions for the printer.

Special identity groups:
Everyone (all current network users).
Network users (users currently accessing a given network resource; a user becomes a member of this group when the user does a network logon to a machine).
Interactive users (users currently accessing a resource on the local computer; a user becomes a member of this group when the user does an interactive logon to a machine).
Authenticated users (users who authenticate to one of the trusted domains).
Service (service accounts used by the service controller to start services under specific accounts become a member of this group).
Principal Self (special identity that is replaced by the SID of the security principal object (user, group, or computer) during Access Check; this wildcard SID lets users and computers have access to their own objects, and lets members of a group have permissions to the group).
Creator/Owner (special identity that is replaced by the Owner SID in the object's security descriptor; this wildcard SID lets the owner of the object automatically have specific access to the object.)

n/a

(Not viewable when you administer groups.)

Windows 2000 uses special identities to represent different users at different times, depending on circumstances. Although you do not see special identities when administering groups and cannot place special identities into groups, you can assign rights and permissions to resources to special identities.

Appendix B: User Rights

User rights are privileges and logon rights. You manage both types with the User Rights policy. For a detailed description of each of the privileges and logon rights listed below, see the "User Rights" chapter in the Windows 2000 Resource Kit.

The following list shows the privileges that can be assigned to a user or group:

  • Act as Part of the Operating System

  • Add Workstations to a Domain

  • Back Up Files and Directories

  • Bypass Traverse Checking

  • Change the System Time

  • Create a Token Object

  • Create Permanent Shared Objects

  • Create a Pagefile

  • Debug Programs

  • Enable Trusted for Delegation on User and Computer Accounts

  • Force Shutdown from a Remote System

  • Generate Security Audits

  • Increase Quotas

  • Increase Scheduling Priority

  • Load and Unload Device Drivers

  • Lock Pages in Memory

  • Manage Auditing and Security Log

  • Modify Firmware Environment Values

  • Profile a Single Process

  • Profile System Performance

  • Replace a Process-Level Token

  • Restore Files and Directories

  • Shut Down the System

  • Take Ownership of Files or Other Objects

  • Unlock a Laptop

The following list shows the logon rights that can be assigned to a user or group:

  • Access This Computer from Network

  • Log On Locally

  • Log On as a Batch Job

  • Log On as a Service

  • Deny Access to This Computer from the Network

  • Deny Logon as a Batch Job

  • Deny Logon as a Service

  • Deny Local Logon

The special user account LocalSystem has almost all privileges and logon rights assigned to it, because all processes that are running as part of the operating system are associated with this account, and these processes require a complete set of user rights.

02/00

1 Some special purpose user accounts used by specific system services also exist (such as IUSR_Servername, which is a built-in account for anonymous access to IIS), but these special user accounts are not under consideration in this paper.
2 When a computer accesses the network, this means that system services running on the computer in the LocalSystem context are accessing the network resources.
3 If you place an external group (or user) directly into a Discretionary Access Control Lists (DACLs), the security identifier (SID) of the user is added to the DACL and, in this case, no foreign security principal object is created. Note that putting individual users onto DACLs is not recommended.
4 The Windows 2000 operating system's global catalog is a database kept on one or more domain controllers. The global catalog plays major roles in logging on users (in a native-mode domain only) and in querying.
5 SAM is a protected subsystem of Windows NT and Windows 2000 that maintains the security accounts management database and provides an API for accessing the database. In Windows NT 4.0, both local and domain security principals are stored by SAM in the registry. In Windows 2000, workstation security accounts are stored by SAM in the local computer registry, and domain controller security accounts are stored in Active Directory.