Windows 2000 Security Technical Overview

Article
12/09/2009

Operating System

Abstract

The distributed security services of the Microsoft® Windows® 2000 Server operating system let organizations identify network users and control their access to resources. The operating system's security model uses trusted domain controller authentication, delegation of trust between services, and object-based access control. Core features include integration with the Windows 2000 Active Directory™ service, support for the Kerberos version 5 authentication protocol for authenticating Windows 2000 users, authentication using public key certificates for external users, Encrypting File System (EFS) for protection of local data, and support for secure communication across public networks using Internet Protocol security (IPSec). In addition, developers can use Windows 2000 security elements in custom applications, and organizations can integrate Windows 2000 security with other operating systems that use Kerberos-based security.

Introduction

Just as the Microsoft® Windows® 2000 Server operating system helps organizations expand their operations through new networking technologies, it also helps them protect their information and networked resources through enhanced security services.

The Windows 2000 distributed security services address key business requirements, including:

The ability to let users logon once and access all enterprise resources.
Strong user authentication and authorization.
Secure communications between internal and external resources.
The ability to set and manage required security policies.
Automated security auditing.
Interoperability with other operating systems and security protocols.
An extensible architecture to support application development that uses Windows 2000 security features.

These features are important elements of the overall Windows 2000 security architecture. Windows 2000 security is based on a simple model of authentication and authorization. Authentication identifies the user when he or she logs on and makes network connections to services. Once identified, the user is authorized access to a specific set of network resources based on permissions. Authorization takes place through the mechanism of access control, using entries stored in Active Directory™ as well as access control lists (ACLs) that define permissions for objects including printers, files, and network file and print shares.

This security model makes it easy for authorized users to work on an extended network, while providing strong safeguards against attack. The Windows 2000 distributed security model is based on trusted domain controller authentication, delegation of trust between services, and object-based access control.

First, each client in a domain establishes a direct trust path by securely authenticating to its domain controller. Second, clients never get direct access to network resources; instead, network services build a client's access token and impersonate the client by using its credentials to carry out requested operations. Third, the Windows operating system kernel uses security identifiers in the access token to verify whether the user is authorized the desired access rights to the target object.

This paper describes the major elements of the Windows 2000 distributed security services that support this model; including Active Directory, authentication and authorization, and an introduction to the Kerberos authentication protocol. It provides an overview of how Windows 2000 uses the public key infrastructure and how the operating system supports certificate services. It also introduces the Encrypting File System (EFS) used to secure data on hard disks. Lastly, it describes how Windows 2000 security services are made available for application developers and how its security services interoperate with those provided by other operating systems.

Note: Each of the topics in this paper is covered in greater detail in materials provided in the Technical Library of the Windows 2000 Web site at https://www.microsoft.com/windows2000/techinfo/default.asp. There you will find white papers on each major technology, as well as the operating system's online documentation and resource kits.

Role of Active Directory

The Windows 2000 Active Directory service plays an essential role in network security. Windows 2000 Server and Windows 2000 Professional each have security features to protect the information stored on individual PCs. But for comprehensive, policy-based security that controls access to networked resources, organizations should use Windows 2000 Server and Professional together so they can take advantage of the distributed security features provided by Active Directory.

Active Directory provides a central place to store information about the users, hardware, applications, and data on the network so users can find what they need. It also stores the authorization and authentication information required to ensure that only appropriate users can access each network resource.

In addition, Active Directory is tightly integrated with Windows 2000 security services such as the Kerberos authentication protocol, public key infrastructure, Encrypting File System (EFS), the Security Configuration Manager, Group Policy, and delegated administration. This integration allows Windows applications to take advantage of the existing security infrastructure, which is a capability described later in this paper.

Active Directory Basics

Because they are so closely intertwined, understanding how security services work in Windows 2000 requires a basic understanding of the Active Directory architecture. If you aren't familiar with Active Directory, this section provides a brief overview.

Note: For more information on Active Directory, explore the resources in the Windows 2000 Technical Library at https://www.microsoft.com/windows2000/technologies/directory/default.asp.

Unlike the flat-file directory used in the Windows NT® Server operating system, Windows 2000 Active Directory stores information in a logical hierarchy that represents your business structure. This allows for greater growth and simplified management. To create this hierarchy, Active Directory uses domains, organizational units (OUs), and objects to let you organize network resources in much the same way Windows uses folders and files to organize information on your PC.

Figure 1: Hierarchical structure of the Active Directory service.

A domain is a collection of network objects, including organizational units, user accounts, groups, and computers, all of which share a common directory database with respect to security. Domains form the core unit of logical structure within Active Directory, and as such play an essential role in security. Grouping objects into one or more domains allows your network to reflect the way your company is organized.

Larger organizations may contain multiple domains, in which case the hierarchy of domains is called a domain tree. The first domain created is the root domain, and is the parent to domains created beneath it, which are called child domains. To support very large organizations, domain trees can be linked together into an arrangement called a forest. (In cases where multiple domain controllers are used, Active Directory is replicated at regular intervals to each domain controller in the domain so that databases are always synchronized.)

A domain identifies a security authority with consistent internal policies and explicit security relationships to other domains. The administrator of a particular domain has rights to set policies within that domain only. This is helpful in large enterprises, because different administrators can create and manage different domains in the organization. This management implication is explored further in the "Delegation of Administration" section below. However, a domain is not a security boundary that provides security isolation from other domains in the same forest; only the forest provides such a security boundary.

Sites is another term you'll come across when learning about Active Directory. While domains typically reflect an organization's business structure, sites are used to define groups of Active Directory servers with respect to geography. These computers are typically connected by a high-speed link, but they may or may not have a logical relationship with one another. For example, if you have a large building housing relatively unrelated corporate activities, such as a video production facility, catering, and document storage, the Active Directory servers in that building may be treated as a site, even though the processing done on the servers is unrelated.

An organizational unit (OU) is a container that you use to organize objects into logical administrative groups within a domain. An OU can contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs.

An object contains information (called attributes) about an individual item, such as a particular user, computer, or piece of hardware. For example, a user object's attributes would likely include name, telephone number, and manager name. A computer's object would likely include the computer's location and an access control list (ACL) that specifies the groups and individuals who have access rights to the computer.

By grouping information into domains and OUs, you can manage security for collections of objects, such as groups of users and computers, rather than for each user and object individually. This concept will be described further in the "Managing Security with Group Policy" section below. First, there's one more concept that's important to understanding how security works with Active Directory: trust.

Trust Relationships Between Domains

To allow users to log on once to a network and then use resources throughout the network (an ability generally referred to as single sign-on), Windows 2000 supports trust relationships between domains. A trust relationship is a logical relationship established between domains to support passthrough authentication, allowing users and computers to be authenticated in any domain in the forest. This lets users or computers access any resources for which they have the appropriate permissions, while only logging on to the network once. This ability to traverse a number of domains illustrates the term transitive trust, which refers to authentication across a chain of trust relationships.

Windows NT–based networks use one-way, non-transitive trust relationships. By contrast, when Windows 2000–based domains are organized into a tree (such as that in Figure 1 above), there are implicit trust relationships created between the domains. This makes it easier to establish trust between domains in mid-size and larger organizations. Domains that are members of the domain tree define a two-way trust relationship with the parent domain in the tree, and all domains implicitly trust other domains in the tree. (If there are specific domains that should not have two-way trust, you can define explicit one-way trust relationships.) For organizations with multiple domains, the overall number of explicit one-way trust relationships is significantly reduced using Windows 2000 compared to Windows NT 4.0, a change which greatly simplifies domain management. Transitive trust is established by default within a tree, which makes sense because a single administrator normally administers a tree. But because forests are not as likely to be controlled by a single administrator, transitive trust relationships between trees in a forest must be specifically established.

For an illustration of how trust relationships work, refer again to Figure 1above. Windows 2000 automatically establishes a two-way trust relationship between the root domain, Microsoft.com, and its two child domains, FarEast.Microsoft.com and Europe.Microsoft.com. In addition, because Microsoft.com trusts both the child domains, a trust relationship is also transitively created between the FarEast and Europe domains. These relationships are automatically established between Windows 2000–based domains. In networks where there are both Windows 2000– and Windows NT–based domains, administrators can create the explicit one-way trust relationships used on Windows NT–based networks.

In Windows 2000, trust relationships support authentication across domains by using Kerberos V5 protocol and NTLM authentication (described below) for backward compatibility. This is important because many organizations have a complex Windows NT–based enterprise domain model with multiple master domains and many resource domains, and they often find it costly and complex to manage the trust relationships between the resource domains and their master account domains. Because the Windows 2000–based domain tree supports a tree of transitive trusts, it lets larger organizations simplify the integration and management of their network domains. Note, however, that transitive trust does not automatically assign rights to anyone that would not otherwise be granted those rights by ACLs. Rather, transitive trust makes it easier for administrators to define and configure access rights.

Managing Security with Group Policy

Group Policy settings are configuration settings an administrator can use to control a variety of behaviors for objects in Active Directory. Group Policy is a significant feature of Active Directory because it lets you apply all types of policies to large numbers of computers in a uniform way. For example, 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 settings to computers at boot time and to users when they log on.

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 define wide-reaching security policies. Domain-level policies apply to all users in a domain and include things such as account policies—for example, the minimum password length or how often should users change their passwords. You can specify whether or not these settings may be overridden at lower levels.

After applying broad policies using the capabilities of Group Policy, you can further refine security settings on individual PCs. Local computer security settings control the rights and privileges you want to grant to a particular user or computer. You can specify, for example, who can do backups and restores on a server, or how much of the data access you want to audit for a desktop computer.

The settings for a particular computer are a combination of all the policy settings that have been set from the domain down to the OU. For example, looking at Figure 1 above, the settings for users in the Europe.Microsoft.com domain are an accumulation of all the policies set at the Microsoft.com domain, the Europe.Microsoft.com domain, and all the OUs above a particular user in Europe.Microsoft.com.

Authentication and Access Control

Authentication is a fundamental aspect of system security. It is used to confirm the identity of any user trying to log on to a domain or access network resources. The Windows 2000 authentication process is part of what enables single sign-on to all network resources. With single sign-on, a user can log on to the domain once, using a single password or smart card, and authenticate to any computer in the domain.

Successful user authentication in a Windows 2000–based computing environment consists of two separate processes: interactive logon, which confirms the user's identification to either a domain account or a local computer, and network authentication, which confirms the user's identification to any network service that the user attempts to access.

Once a user account has been authenticated and can access an object, either the user rights that are assigned to the user or the permissions that are attached to the object determine the type of access granted. For objects within a domain, the object manager for that object type enforces access control. For example, the registry enforces access control on registry keys.

The remainder of this section describes the Windows 2000 authentication process and access control provisions in more detail.

Authentication

A user must have a Windows 2000 user account stored in Active Directory to log on to a computer or to a domain. The account establishes an identity for the user and then the operating system uses this identity to authenticate the user and grant 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.

Like user accounts, Windows 2000 computer accounts provide a means for authenticating and auditing the computer's access to the network and its access to domain resources. Each Windows 2000–based computer to which you want to grant access to resources must have a unique computer account.

Note: 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–based domains. However, you can log on to a network and use Windows 98– and Windows 95–based computers in Active Directory domains.

Windows 2000 supports multiple authentication mechanisms for proving the identities of users as they enter your network. This is important when extending your network to users outside of your company with extranets and e-commerce applications.

When a user enters the network, he or she needs to provide authentication information so the security system can verify his or her identity before determining what access, if any, that user is permitted to network resources. The Kerberos authentication protocol (described below) is used to authenticate Windows 2000 users within your company. As you extend your systems to partners, suppliers, and customers over the Internet, you need to support multiple ways for users outside your company to prove their identity.

To help you meet this requirement, Windows 2000 supports a number of industry-standard authentication mechanisms, including X.509 certificates, smart cards, and the Kerberos protocol. Additionally, Windows 2000 supports the NTLM protocol used for years in Windows and provides interfaces for vendors that make biometric authentication mechanisms.

Using Group Policy in Active Directory, you can assign a specific authentication mechanism to an individual user or group of users based on their roles and your security needs. For example, you may require your executive staff to authenticate only with smart cards to provide an extra element of security when proving their identities; for Internet customers, you may require authentication with X.509 certificates that can be used with any browser; and for internal employees, you may continue to use NTLM username/password authentication. Regardless of the method used to prove identity, Windows 2000 consistently uses Active Directory to look up the identity presented by the authentication mechanism.

If authentication is successful and an account can be found for the user based on the identity provided by the authentication mechanism, Windows 2000 provides the user with a set of credentials that can be used throughout the network to access resources.

Access Control

Windows 2000 implements access control by letting administrators assign security descriptors to objects, such as files, printers, and services. An object's security descriptor includes an access control list (ACL), which defines which users (either by individual or by group) have permission to perform particular actions with that object. An object's security descriptor also specifies the various access events to be audited for that object, such as all write activities to a secured file. By managing properties on objects, administrators can set permissions, assign ownership, and monitor user access.

Not only can administrators control access to a specific object, they can also control access to a specific attribute of that object. For example, through proper configuration of an object's security descriptor, a user could be allowed to access a subset of information, such as employees' names and phone numbers, but not their home addresses.

Using an object's ACL, Windows 2000 compares information about the client and the information about the object to determine whether the user has the desired access rights (for example, read/write permission) to that object (for example, a file). The access check is done in kernel mode within the security subsystem of Windows 2000. Depending on the outcome of this comparison, the service will respond to the client, either serving the object or returning an access-denied failure.

Fine-grained Access Control

To give administrators greater flexibility in assigning security settings, Active Directory provides fine-grained access control for objects in the directory. Entries in the directory can have a rich schema: A user or group can have literally hundreds of attributes, like telephone number, office number, manager, and the groups a member belongs to. You can grant permissions to selected properties, or attributes, of that user account without granting full read/write permission to all of the attributes. You can also audit the changes to the client account or to other Active Directory records, per property.

Delegation of Administration

So that organizations can distribute responsibility for domain management among a number of employees, Active Directory lets administrators delegate subsets of administrative tasks within a forest or within a domain. You can delegate administrative control to any level of a domain tree by creating organizational units that encompass the objects over which you want to delegate control, and then delegating administrative control for those OUs to particular users or groups.

At the OU level, an administrator can grant permissions for specific operations, such as who can create groups, who can control membership lists for those groups, or who can add computer accounts to the domain. Group Policy settings and user groups let administrators precisely define delegated authority. For example, the authority to modify user records can be delegated to a specific user group, such as the Accounting Support Team, and that group's authority can in turn be limited to selected subsets of users, such as just the accounting payroll clerks.

Further, because of fine-grained access control (described above), administrators can narrowly define the scope of delegated tasks. For example, rather than having to give the support group full access to user account records, an administrator can give the support group the ability to reset a user's password, but not the ability to change his or her address.

Note: For more information about the relationship between Active Directory and security, see the "Active Directory Users, Computers, and Groups" white paper in the Windows 2000 Server Technical Library at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/adusers.mspx.

Kerberos Authentication Protocol

Windows 2000 uses the Internet standard Kerberos V5 protocol (RFC 1510) as the primary method for authenticating users. The Kerberos protocol provides a mechanism for mutual authentication between a client and a server before a network connection is opened between them. This approach is ideal for a network that includes open communications, such as those conducted over the Internet.

Kerberos authentication is based on tickets. When a client logs on to a Windows 2000–based domain, it receives a ticket that is used to validate the client to the network resource being accessed, and to validate the network resource to the client. To do so, the Kerberos protocol relies on an authentication technique called shared-secret authentication. The premise behind this method is simple: If only two people know a secret, then either person can confirm the identity of the other by confirming that the other person knows the secret.

With the Kerberos protocol, both clients and servers are registered with a Kerberos authentication server. Clients using Kerberos authentication send encrypted information derived from the user's password to the Kerberos server, which uses it to verify the user's identity. Likewise, the server sends information to the Kerberos software on the client, which can then verify the identity of the server. This mutual authentication process, described in more detail below, protects both the client and the server from being impersonated by a malicious user.

This method is an improvement over the Windows NT 4.0 authentication process (referred to as NTLM), which requires a separate client authentication for each network resource the user accesses. Kerberos replaces NTLM as the primary security protocol for access to resources within or across Windows 2000 Server–based domains. (To ensure backward compatibility, NTLM is still supported.) Full Kerberos protocol support provides fast, single sign-on to Windows 2000 Server–based resources as well as other environments that support this protocol.

Kerberos Authentication Process

In the simplest terms, the Kerberos authentication process works by checking and passing credentials between clients and servers. Here's how it works: When a user logs on to a Windows 2000–based domain, Windows 2000 locates an Active Directory server and Kerberos authentication service, and delivers the client's credentials to the Kerberos service. The client is authenticated by means of a password that is used to derive a key that can be verified by the server, or (in the case of a smart-card logon) by information encrypted using a private key whose public half is registered in Active Directory. After checking the client's authentication information, a Kerberos service, called the Key Distribution Service (KDC), issues a ticket-granting ticket (TGT) to the user, which is then used to identify the client as it requests subsequent Kerberos tickets for logging on to network resources. (Using a TGT reduces the number of times the KDC has to look up client information.) Although this is a complex process, the only portion the user is aware of is entering his or her password to log on.

Figure 2 below shows the relationship between the client, the KDC, and the application server using the Kerberos authentication protocol.

Figure 2: Kerberos authentication process.

Kerberos and Active Directory

Every Windows 2000–based domain controller implements Active Directory as its directory and integrates the KDC. This allows all user account information to be stored in a single directory. If your organization is medium-sized or larger, you will likely have multiple domain controllers to provide availability and capacity for your organization. This won't affect your ability to use Kerberos authentication because wherever there is a copy of Active Directory there is also a copy of the Kerberos authentication service.

Delegation of Authentication

So far this discussion has addressed situations where a client accesses a single server. However, it is fairly common for applications to use several servers to perform a task. For example, a Web-based application may use both a Web server and a database server to provide information to a browser-based client. Rather than have the client go through a separate authentication process for each server it uses, Windows 2000 provides security across multi-tier applications (also called three-tier applications).

As described earlier, the transitive trust relationships between Windows 2000–based domains greatly extend the scope of resources that a client running Windows 2000 or Windows NT Workstation can access after logging on to a Windows 2000–based domain, without requiring a number of different passwords to access different servers and resources. This scope of access, referred to as single sign-on, is made possible by the combination of the Windows 2000 trust mechanisms and the way the Kerberos protocol works with Active Directory to handle client authentication.

The operating system provides a single security model and infrastructure for defining the user accounts and managing the access permissions. This means that you can define settings once in Active Directory and have them used consistently by all the application servers in your organization. The method used to support the three-tier model is called delegation of authentication.

Figure 3: Delegation of authentication.

As shown in Figure 3 above, this model lets the client hand off authentication to the servers involved in the application. The servers impersonate the client and carry out access requests on the client's behalf. This means all passing of authentication credentials and tickets takes place without the user having to provide input to the process. Although the server impersonates the client, an audit trail to the originating client is preserved. When a server processes a request forwarded by another server, its log will show the client's name rather than that of the intermediary server.

This model is an important element of Windows 2000, because it supports single sign-on and simplifies, without compromising, security. Many applications today require a separate account database for security. But applications that use Active Directory as a central store for security information help create a network that is far simpler to manage and scale.

Note: For more detail on Kerberos authentication, see the "Windows 2000 Kerberos Authentication" and "Windows 2000 Kerberos Interoperability" white papers in the Windows 2000 Technical Library at https://www.microsoft.com/windows2000/techinfo/default.asp.

Public Key Infrastructure

Public key cryptography is used to secure activity on open networks, such as the Internet. It lets you encrypt data, sign it, and verify the identity of clients and servers by using certificates. The challenge with this technology is tracking the certificates. A public key infrastructure (PKI) provides the capability to use, manage, and find public key certificates. This section describes PKI in more detail and explains how Windows 2000 PKI functions.

PKI is an industry-standard system of digital certificates, certification authorities (CAs), and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction. You can use your public key infrastructure to support a wide range of network and information security needs. For example, users who do not have Windows 2000 accounts on your network, such as business partners, need another way to prove their identity so you can control their access to information. These users can be authenticated using PKI.

Public key certificates are used to validate and transport encrypted keys used to encrypt and decrypt data. There are two types of keys used in public key cryptography, a public key and a private key. The public key is made broadly available in certificates, but data that is encrypted by the public key can only be decrypted using the private key. A secured transaction requires both the public and the private keys to encrypt and decrypt the data contained within the transaction.

Windows 2000 PKI provides the framework of services, technology, protocols, and standards that enable you to deploy and manage a strong information security system that is based on public key technology. The PKI capability in Windows 2000 supports public-key cryptography by letting applications and users easily locate and use certificates without needing to know where they are stored or how they work. Moreover, Windows 2000 PKI is fully integrated with Active Directory and with the operating system's distributed security services.

Figure 4: Windows 2000 public key infrastructure components.

PKI Certificate Support

A certificate is basically a digital statement issued by an authority that vouches for the identity of the holder of a private key. A certificate binds a public key to the identity of the person, computer, or service that holds the corresponding private key.

The standard certificate format used by Windows 2000 certificate-based processes is X.509v3. An X.509 certificate includes information about the person or entity to which the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate.

Certificate Services

So that you can implement PKI without depending on an external CA, Windows 2000 includes a component called Certificate Services to create and manage CAs. Certificate Services is integrated with Active Directory and distributed security services, as shown in Figure 4 above.

A CA is responsible for establishing and vouching for the identity of certificate holders. A CA also revokes certificates if they should no longer be considered valid and publishes certificate revocation lists (CRLs) to be used by certificate verifiers. The simplest PKI design has only one root CA. In practice, however, the majority of organizations deploying a PKI will use a number of CAs, organized into trusted groups known as certification hierarchies.

A separate component of Certificate Services is the CA Web enrollment pages. These Web pages are installed by default when you set up a CA and allow certificate requesters the ability to submit certificate requests using a Web browser. Additionally, the CA Web pages can be installed on Windows 2000–based servers that do not have a certification authority installed. In this case, the Web pages are used to direct certificate requests to a CA that, for whatever reason, you do not want requesters to access directly. If you choose to create custom Web pages for your organization to access a CA, the Web pages provided in Windows 2000 can be used as samples.

To make it easy to deploy public key security, the steps for enrolling for the certificates used by computers are automated within Windows 2000. As part of using Active Directory, server computers will be aware of the fact that they can obtain a certificate, and will automatically obtain one when needed. This means the server administrator doesn't have to go to each server and go through manual steps to enroll for server certificates.

Public Key Policies

You can use Group Policy in Windows 2000 to distribute certificates to computers automatically, establish certificate trust lists and lists of trusted certification authorities, as well as manage recovery policies for the encrypting file system.

CryptoAPI

In addition to Certificate Services, Windows 2000 PKI relies on Microsoft CryptoAPI version 2 for secure cryptographic operations and private key management. CryptoAPI is a Windows 2000 application programming interface (API) that provides cryptographic services for Windows and Windows applications. It provides a set of functions that allow applications to encrypt or digitally sign data flexibly, while providing protection for private keys. Independent modules known as cryptographic service providers (CSPs) perform the actual cryptographic functions.

Developers can use the CryptoAPI to integrate certificate services with existing databases and third-party directory services. Common uses for CryptoAPI include support for customized processes to protect electronic documents.

Using Certificates to Authenticate External Users

There are a number of situations in which you'll want to provide external users with secure access to specific data published on a Web site that is not generally available to the public. Typical circumstances include corporate partners who need extranet access; a department that needs access to another department's intranet pages; or a part of the public to whom you want to provide selective access.

Windows 2000 provides a way to securely grant access to external users by authenticating their identity using PKI and Active Directory. Here's a general overview of how it works: You provide access by creating a user account designated for external users in Active Directory. The account has access to the resources an external user may use on your network. Each external user needs to have a certificate to validate their identity. That certificate must be issued by a certification authority listed in the certificate trust list for the Active Directory site, domain, or organizational unit in which you have created the user account. When the user logs on, the system maps his or her certificate to the account, and determines what portions of your internal Web site he or she may use. The authentication process is transparent to the external user.

Where PKI Is Used in Windows 2000

In addition to providing a way for external users to verify their identity, there are other situations that rely on PKI. Common security functions that use public key technology include:

Securing e-mail communications using Secure/Multipurpose Internet Mail Extensions (S/MIME).
Creating digital signatures for secure transactions.
Securing communications over the Web using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).
Signing executable code for delivery over public networks.
Supporting local or remote network logon.
Providing Internet Protocol security (IPSec) authentication for clients that do not use the Kerberos protocol, or for shared-secret passwords for IPSec communications.
Encrypting files using Windows 2000 EFS.
Securing logon credentials using smart cards.

Some of these circumstances, including EFS, IPSec, and smart cards, are described elsewhere in this paper.

Note: For information on the other uses for PKI in Windows 2000, see the Technical Library at https://www.microsoft.com/windows2000/techinfo/default.asp.

Smart Cards

Companies are increasingly looking for ways to increase the security of their networked resources. One of the methods gaining popularity is the use of smart cards. Smart cards are a relatively simple way to make it much harder for an unauthorized person to gain access to a network. For that reason, Windows 2000 includes built-in support for smart card security.

Smart cards, which are typically the size of a credit card, provide tamper-resistant storage for protecting user's certificates and private keys. In this way, smart cards provide a very secure means of user authentication, interactive logon, code-signing, and secure e-mail. The smart card contains a chip that stores the user's private key, logon information, and public key certificate used for various purposes, such as digital signatures and data encryption.

Smart cards are more secure than passwords for several reasons:

A physical object, the card, is needed to authenticate the user.
The card must be used with a personal identification number (PIN), helping to ensure that the proper person is using the card.
The risk of an attacker using a stolen credential is effectively eliminated, since it is physically impossible to extract the key from the card.
Without the card, an attacker cannot access smart card–protected resources.
No form of the password or any reusable information is transmitted over the network.

Smart cards enhance software-only authentication by requiring a user to provide both a physical object (the card) and required knowledge (the card's PIN number) before being able to access a resource. This requirement for presenting both the card and the PIN is referred to as two-factor authentication. Using a smart card to authenticate users is ideal for situations where extra security is important, as in providing access to your payroll software.

Instead of entering a password, the user inserts a card into a reader attached to the PC, and enters the card's PIN. Windows 2000 uses the private key and certificate that is stored on the card to authenticate the user to the KDC on a Windows 2000 domain controller. After authenticating the user, the KDC returns a ticket-granting ticket. From this point on, additional connections the user makes during the session use Kerberos authentication as described above.

Encrypting File System

So far, this paper has described techniques for protecting resources stored on a centralized network. But beyond simple password protection, what about protecting the data stored on a desktop or laptop computer?

Windows 2000 Encrypting File System (EFS) addresses this concern. For added protection of data stored locally, EFS lets you encrypt designated files or folders on a local computer, so unauthorized people can't read those files. EFS is particularly useful for protecting data on a computer that might be physically stolen, such as a laptop. You can configure EFS on laptops to ensure that all business information is encrypted in the user's document folders.

When you enable EFS for a file or folder on an NTFS file system (NTFS) volume, the operating system encrypts the files using the public key and symmetric encryption algorithms available through the CryptoAPI. Though the underlying mechanism is complicated, administrators and users can take advantage of the extra security by merely selecting a check box in the Advanced Attributes dialog box accessed from the File Properties dialog box.

EFS automatically encrypts the file when it is saved, and decrypts it when the user opens it again. No one can read these files except the user who encrypted the file and an administrator with an EFS file recovery certificate (see below). Since the encryption mechanism is built into the file system, its operation is transparent to the user and extremely difficult to attack.

EFS encrypts a file using a symmetric encryption key unique to each file. Then it encrypts the encryption key as well, using the public key from the file owner's EFS certificate. Since the file owner is the only person with access to the private key, that person is the only one who can decrypt the key, and therefore the file.

Encryption protects files even if someone bypasses EFS and uses low-level disk utilities to try to read information. Even if the file can be stolen, over the network or physically, it cannot be decrypted without first logging on to the network as the appropriate user. Since it cannot be read, the file also cannot be surreptitiously modified.

In the event of an emergency, or should an employee leave your organization, EFS includes a recovery mechanism that lets you recover your company's information. When EFS is used, a separate recovery key is created. This is done automatically by the system, which encrypts the original encryption key using the public key of an administrator's EFS file recovery certificate. An administrator can use the private key from that certificate to recover the file should the need arise.

Security Configuration Templates

To make it easier to set up and manage the security settings for an organization's network, Windows 2000 Server includes the Security Templates tool. This Microsoft Management Console (MMC) snap-in lets administrators define standard templates and apply them uniformly to multiple computers or users.

A security template is a physical representation of a security configuration; in other words, it is a file where a group of security settings may be stored. Windows 2000 includes a set of standard security templates, each appropriate to the role of a computer: The templates range from security settings for low security domain clients to highly secure domain controllers. These templates can be used as provided, modified, or serve as a basis for creating custom security templates.

The Security Configuration and Analysis tool is a companion to the Security Templates snap-in. It is used to apply the restrictions defined in a security template to actual systems. It can also be used to analyze a system's security and to compare the settings on computers that have been deployed to make sure they conform to company standards.

Secure Networking with IPSec

So far this paper has addressed security issues related to users accessing a Windows 2000–based network and with protecting information stored on local disks. Another area of particular concern in networked security is the protection of data as it is traveling over the network. To address this concern, Windows 2000 incorporates Internet Protocol security (IPSec).

IPSec is a suite of Internet-standard protocols that allow secure, encrypted communications between two computers over an insecure network. The encryption is applied at the IP network layer, which means that it is transparent to most applications that use specific protocols for network communication. Further, IPSec provides end-to-end security, meaning that the IP packets are encrypted by the sending computer, are unreadable en route, and can be decrypted only by the recipient computer. For further safety, the process uses encryption algorithms to generate a single encryption key that is used at both ends of the connection, so the key does not need to be passed over the network.

IPSec can be configured to perform one or more of the following security functions:

Authenticate the sender of IP data packets on the basis of Kerberos authentication, digital certificates, or a shared-secret key (password)
Ensure the integrity of the IP data packets that are transmitted over the network
Encrypt all data that is sent over the network with full confidentiality
Hide the originating IP addresses while they are en route

These capabilities allow you to ensure that network traffic is safe from data modification while en route, and is safe from interception, viewing, or copying by unauthenticated parties.

As with other security policies, you can apply IPSec policies at the local level or the domain level.

Extensible Architecture

To provide compatibility with existing clients and to take advantage of specialized security mechanisms, Windows 2000 supports multiple security protocols. The structural element of the operating system that provides this support is called the Security Support Provider Interface (SSPI). This is a Windows 32 API that applications and system services (such as Microsoft Internet Explorer and Internet Information Services) use to take advantage of security mechanisms, while hiding the complexity of network authentication security protocols from applications. In addition, using SSPI ensures consistent security in the Windows-based environment. Figure 5 below illustrates how SSPI sits between specific security mechanisms and the processes that use them.

Figure 5: SSPI links application protocols to security protocols.

Application developers can take advantage of SSPI to create applications that use the Windows 2000 security protocols. Simply put, SSPI provides an application interface that can create authenticated connections. SSPI acts as a middle-layer process—the specific method used for authentication is hidden from the application, so administrators can choose from a variety of security support providers (SSPs) without being concerned with compatibility. For example, Kerberos authentication and NTLM are implemented as SSPs in Windows 2000, so applications written to SSPI can use either NTLM or Kerberos authentication, depending on the configuration of the client and server.

Interoperability

As you've seen, Windows 2000 implements the standard Kerberos network authentication protocol to improve security and interoperability. Because the Kerberos protocol has been implemented on a number of operating system platforms, it is possible to mix and match the Kerberos technology implemented in Windows 2000 with other Kerberos implementations. This lets you integrate your Windows 2000 network security with the security infrastructure for other operating systems so, for example, you can let UNIX-based clients log on to Windows 2000–based servers and vice versa. (Microsoft has demonstrated interoperability with leading third-party Kerberos implementations. For additional details, see the "Windows 2000 Kerberos Interoperability" white paper cited below.)

The mixing-and-matching of security elements involves three primary variables:

The Kerberos client used to authenticate users to Kerberos services
The Kerberos KDC that provides authentication services for a realm (in the Kerberos protocol, a realm is equivalent to a Windows 2000–based domain)
The access method and network resources to be authenticated

With Windows 2000 Kerberos support, you can authenticate with any system that supports Kerberos V5. You can also set up trust relationships between UNIX–based realms and Windows 2000–based domains.

Note: For specific information about Kerberos interoperability, see the "Windows 2000 Kerberos Interoperability" white paper at https://www.microsoft.com/windows2000/techinfo/howitworks/security/kerbint.asp.

Auditing

Once you have set up a security infrastructure, you need to be able to ensure that it's working properly. That's why establishing an audit trail is an important aspect of security. Monitoring the creation or modification of objects gives you a way to track potential security problems, helps assure user accountability, and provides evidence in the event of a security breach.

To help you do this, Windows 2000 includes security-auditing features that let you monitor security-related events (such as failed logon attempts) so you can detect intruders and attempts to compromise data on the system. The Windows 2000 auditing function provides much greater detail than that available with Windows NT 4.0.

The most common types of events to be audited are:

Access to objects, such as files and folders
Management of user and group accounts
When users log on to and log off of the system

In addition to auditing security-related events, Windows 2000 generates a security log and provides a way for you view the security events reported in the log.

Summary

The security infrastructure in Windows 2000 combines the protection of strong security for networked resources with the efficiency of an advanced management infrastructure. A great example of how this integration affects a typical organization is support for single sign-on, which lets Windows 2000 and Windows NT users access all the resources on a network after they have provided a password or inserted a smart card just once.

Windows 2000 security integrates the centralized information store and policy-based control provided by Active Directory with industry standard protocols for cross-platform, secure connections between clients and servers.

In addition, Windows 2000 includes integrated the public key infrastructure components to support advanced security features such as smart cards for two-factor authentication and EFS for secure on-disk data storage.

To extend the capabilities of an organization that uses Windows 2000, application developers can take advantage of the Windows 2000 security infrastructure using the SSPI, which allows them to use Windows 2000 security features in custom applications. In addition, the operating system's use of the standard Kerberos V5 protocol makes it possible for organizations to integrate Windows 2000 security with that provided by other Kerberos-compatible operating systems.

For managing security within Windows 2000, the operating system includes templates for simplifying the task of setting up and applying security settings. And finally, auditing features help administrators verify that the security system is functioning properly.

For More Information

For the latest information on Windows 2000 Server, check out Microsoft TechNet and our Web site at https://www.microsoft.com/windows2000.

07/00