Secure Networking Using Windows 2000 Distributed Security Services

Operating System

Abstract

Today's Microsoft® Windows NT® Server offers excellent security services for account management and enterprise-wide network authentication. Large organizations need flexibility to delegate account administration and manage complex domains. Internet security concerns are driving the development of public-key security technology that must be integrated with Windows security. To meet these expanding needs, Microsoft is developing Windows 2000 Distributed Security Services.

This paper examines the components of the Windows 2000 Distributed Security Services and provides details on their implementation.

On This Page

Introduction
Windows 2000 Distributed Security Services
Active Directory and Security
Multiple Security Protocols
Kerberos Authentication Protocol
Internet Security for Windows 2000
Interbusiness Access: Distributed Partners
Enterprise and Internet Single Sign-on
Providing a Smooth Migration to Next-Generation Domains
Summary

Introduction

The Microsoft® Windows NT® operating system has excellent security features for the enterprise. A single sign-on to the Windows NT domain allows user access to resources anywhere in the corporate network. Easy-to-use administrator tools for security policy and account management reduce the cost of deploying Windows NT. The Windows NT domain model is flexible and supports a wide range of network configurations from a single domain at one location to multimaster domains spanning the globe.

Windows NT also provides a foundation for integrated security for the BackOffice® family of application services, including Microsoft Exchange, SQL Server™, SNA Server, and Microsoft Systems Management Server. The Windows NT security model provides a solid framework for deploying client/server applications for the enterprise. Today, enterprise is opening up to the Internet. Businesses need to interact with partners, suppliers, and customers using Internet-based technologies. Security is essential for controlling access to resources in an enterprise network, intranets, and Internet-based servers.

Intranets are quickly becoming the most effective way to share information for many different business relationships. Today, access to nonpublic business information by outside parties is controlled by creating user accounts for those who are part of the extended business family. Partnerships help define the trust relationships that once applied only to employees who used corporate assets, but that now include many more people.

Security technologies are also changing rapidly. Public-key certificates and dynamic passwords are two technology areas that are growing rapidly to meet higher-level security needs in today's environment. Remote access over public networks and Internet access for interbusiness communication are driving the evolution of security technology. The Windows NT security architecture is uniquely positioned to take advantage of these and other technology advances. Windows NT combines ease of use, excellent administration tools, and a solid security infrastructure that supports both enterprise and the Internet.

Windows 2000 Distributed Security has many new features to simplify domain administration, improve performance, and integrate Internet security technology based on public-key cryptography. The highlights of the Windows 2000 Distributed Security Services include:

• Integration with Windows 2000 Active Directory to provide scalable, flexible account management for large domains with fine-grain access control and delegation of administration.

• Kerberos version 5 authentication protocol, a mature Internet security standard, which is implemented as the default protocol for network authentication; it provides a foundation for authentication interoperability.

• Strong authentication using public-key certificates, secure channels based on Secure Sockets Layer (SSL) 3.0, and CryptoAPI to deliver industry-standard protocols for data integrity and privacy across public networks.

This paper describes the next generation of Windows distributed security, which provides features to support the demands of the Internet-based enterprise. Most of the material described here is delivered in Windows 2000, though some features have already been implemented in Windows NT 4.0, as noted in the text.

Windows 2000 Distributed Security Services

There are many areas in which Windows 2000 security is adapting to support the Internet-based enterprise. Some of these changes reflect advances in supporting large organizations through the use of the hierarchical Windows 2000 Active Directory. Other changes take advantage of the flexibility of the Windows security architecture to integrate authentication using Internet public-key certificates.

The list below introduces the new Windows 2000 security features:

• The Active Directory provides the store for all domain security policy and account information. The Active Directory, which provides replication and availability of account information to multiple Domain Controllers, is available for remote administration.

• The Active Directory supports a hierarchical name space for user, group, and computer account information. Accounts can be grouped by organizational units, rather than the flat domain account name space provided by earlier versions of Windows NT.

• Administrator rights to create and manage user or group accounts can be delegated to the level of organizational units. Access rights can be granted to individual properties on user objects to allow, for example, a specific individual or group to have the right to reset passwords, but not to modify other account information.

• Active Directory replication allows account updates at any domain controller, not just the primary domain controller (PDC). Multiple master replicas of the Active Directory at other domain controllers, which used to be known as backup domain controllers (BDCs), are updated and synchronized automatically.

• Windows 2000 employs a new domain model that uses the Active Directory to support a multilevel hierarchy tree of domains. Management of trust relationships between domains is simplified through tree-wide transitive trust throughout the domain tree.

• Windows security includes new authentication based on Internet standard security protocols, including Kerberos Version 5 and Transport Layer Security (TLS) for distributed security protocols, in addition to supporting Windows NT LAN Manager authentication protocols for compatibility.

• The implementation of secure channel security protocols (SSL 3.0/TLS) supports strong client authentication by mapping user credentials in the form of public-key certificates to existing Windows NT accounts. Common administration tools are used to manage account information and access control, whether using shared secret authentication or public-key security.

• Windows 2000 supports the optional use of smart cards for interactive logon, in addition to passwords. Smart cards support cryptography and secure storage for private keys and certificates, enabling strong authentication from the desktop to the domain.

• Windows 2000 provides the Microsoft Certificate Server for organizations to issue X.509 version 3 certificates to their employees or business partners. This includes the introduction of the CryptoAPI for certificate management and modules to handle public-key certificates, including standard format certificates issued by either a commercial Certificate Authority (CA), third-party CA, or the Microsoft Certificate Server included in Windows. System administrators define which CAs are trusted in their environment and, therefore, which certificates are accepted for client authentication and access to resources.

• External users who do not have Windows 2000 accounts can be authenticated using public-key certificates and mapped to an existing Windows account. Access rights defined for the Windows account determine the resources that the external users can use on the system. Client authentication, using public-key certificates, allows Windows 2000 to authenticate external users, based on certificates issued by trusted Certificate Authorities.

• Windows 2000 users have easy-to-use tools and common interface dialogs for managing the private/public-key pairs and the certificates that they use to access Internet-based resources. Storage of personal security credentials, which uses secure disk-based storage, is easily transported with the proposed industry-standard protocol, Personal Information Exchange. The operating system also has integrated support for smart card devices.

• Encryption technology is engineered into the operating system in many ways to take advantage of the use of digital signatures for providing authenticated data streams. In addition to signed ActiveX™ controls and Java Classes for Internet Explorer, Windows 2000 uses digital signatures for image integrity of a variety of program components. In-house developers can also create signed software for distribution and virus protection.

In addition to these changes, we expect third parties to host dynamic password authentication services on Windows 2000 Server and to integrate dynamic passwords with Windows 2000 domain authentication. The APIs and documentation to support these third-party products are available in the Microsoft Platform SDK.

Each of the new features of Windows 2000 security is described in more detail in the following sections.

Active Directory and Security

Windows NT account information is maintained today using a secure portion of the registry on the domain controllers. Using domain trust and pass-through authentication, a two-level hierarchy of domains provides some flexibility for organizing account management and resource servers. Within a domain, however, accounts are maintained in a flat-name space with no internal organization.

Windows 2000 Distributed Security Services use the Active Directory as the repository for account information. The Active Directory provides significant improvement over the registry-based implementation in the areas of performance and scalability, and offers a feature-rich administrative environment.

The following diagram shows the hierarchical structure for a tree of Windows 2000 domains, and the hierarchical name context within each domain using organizational units (OUs) as directory object containers.

Figure 1: Hierarchical structure of the Active Directory

The advantages of integrating security account management with the Active Directory are:

• Accounts for users, groups, and machines can be organized into directory containers called organizational units (OUs). A domain can have any number of OUs organized in a tree-structured name space. Businesses can organize the name space for account information to represent the departments and organizations in the company. User accounts, as well as OUs, are directory objects that can easily be renamed within the domain tree as the organization changes.

• The Active Directory supports a much larger number of user objects (more than 1 million objects) with better performance than the registry. Individual domain size is no longer limited by performance of the security account repository. A tree of connected domains can support much larger, complex organizational structures.

• Administration of account information is enhanced using advanced graphical tools for Active Directory management, as well as through OLE DS support for scripting languages. Common tasks can be implemented using batch scripts to automate administration.

• Directory replication services support multiple copies of account information in which updates can be made at any copy, not just the designated primary domain controller. The Lightweight Directory Access Protocol (LDAP) and directory synchronization support provide the mechanisms to link the Windows directory with other directories in the enterprise.

Storing the security account information in the Active Directory means that users and groups are represented as objects in the directory. Read and write access to objects in the directory can be granted to the object as a whole, or to individual properties of the object. Administrators have fine-grain control over who can update user or group information. For example, a Telecom operator group can be granted write access only to user account properties related to office telephone equipment without requiring full Account Operator or Administrator privileges.

The concept of a group is also simplified because local and global groups are both represented by group objects in the directory. Existing programming interfaces for local group access are still supported for complete backward compatibility. However, groups defined in the directory can be used for domain-wide access control to resources or only for local administration purposes on the domain controller.

A fundamental relationship exists between the Active Directory and the Security Services integrated into the Windows 2000 operating system. The Active Directory stores domain security policy information—such as domain-wide password restrictions and system access privileges—that have direct bearing on use of the system. Security-related objects in the directory must be securely managed to avoid unauthorized changes that affect overall system security. The Windows 2000 operating system implements object-based security model and access control for all objects in the Active Directory. Every object in the Active Directory has a unique security descriptor that defines access permissions that are required to read or update the object properties.

The diagram below shows the fundamental relationship between the Active Directory and operating system security services.

Figure 2: Relationship between the Active Directory and Security Services

The Active Directory uses impersonation and Windows 2000 access verification to determine if an Active Directory client can read or update the desired object. This means LDAP client requests to the directory require the operating system to enforce access control, rather than having the Active Directory itself make the access-control decisions.

The Windows 2000 security model provides a unified and consistent implementation of access control to all domain resources, based on group membership. Windows 2000 security components can trust the security related information stored in the directory. For example, the Windows 2000 authentication service stores encrypted password information in a secure portion of the directory user objects. The operating system trusts that security policy information is stored securely and that account restrictions or group membership is not changed by anyone without authorized access. In addition, security policy information for overall domain management is kept in the directory.

This fundamental relationship of Security and the Active Directory is achieved only by complete integration of the directory with the Windows 2000 operating system and is not otherwise available.

Domain Trust Relationships

Windows 2000 domains can be organized into a hierarchical domain tree. The trust relationships between domains allow users with accounts defined in one domain to be authenticated by resource servers in another domain. In Windows NT 4.0 and earlier versions, interdomain trust relationships are defined by one-way trusted domain accounts between domain controllers. Management of the trust relationships between account domains and resource domains on a large network is a complex task.

The Active Directory supports two forms of trust relationships:

• Explicit one-way trust relationships to Windows NT 4.0 domains.

• Two-way transitive trust between domains that are part of the Windows 2000 domain tree.

The diagram below shows the two styles of trust relationship.

Figure 3: Domain trust relationships

Transitive trust between domains simplifies the management of interdomain trust accounts. Domains that are members of the domain tree define a two-way trust relationship with the parent domain in the tree. All domains implicitly trust other domains in the tree. If there are specific domains that do not want two-way trust, explicit one-way trust accounts can be defined. For organizations with multiple domains, the overall number of explicit one-way trust relationships is significantly reduced.

Delegation of Administration

Delegation of administration is a valuable tool for organizations to confine the security administration to apply only to defined subsets of the entire organization domain. The important requirement is to grant rights to manage a small set of users or groups within their area of responsibility and, at the same time, not give permissions to manage accounts in other parts of the organization.

Delegation of responsibility to create new users or groups is defined at the level of an organizational unit (OU), or container, where the accounts are created. Group administrators for one organizational unit do not necessarily have the ability to create and manage accounts for another organizational unit within a domain. However, domain-wide policy settings and access rights defined at higher levels in the directory tree can apply throughout the tree using inheritance of access rights.

There are three ways to define the delegation of administration responsibilities:

• Delegate permissions to change properties on a particular container, such as the LocalDomainPolicies of the domain object itself.

• Delegate permissions to create and delete child objects of a specific type beneath an OU, such as Users, Groups, or Printers.

• Delegate permissions to update specific properties on child objects of a specific type beneath an OU; for example, the right to set passwords on User objects.

The Directory Service Administration user interface makes it easy to view the delegation information defined for containers. Adding new delegation of permissions is also easy to do by selecting whom you want to delegate permission to, and then choosing which permissions they need.

Integrating the security account repository with the Active Directory provides real benefits to manage an enterprise. Performance, ease of administration, and scalability for large organizations are the direct result. Internet-based enterprises can use domain trees and hierarchical OUs to organize accounts for business partners, frequent customers, or suppliers with specific access rights to their system.

Fine-Grain Access Rights

Large organizations typically depend on many individuals or groups to secure and manage the network account infrastructure. They need the ability to grant access rights for specific operations—such as resetting user passwords or disabling accounts—to specific groups without also granting permission to create new accounts or change other properties of user accounts.

The security architecture for Active Directory objects uses Windows 2000 security descriptors to control object access. Every object in the directory has a unique security descriptor. The Access Control List (ACL) in the security descriptor is a list of entries that grant or deny specific access rights to individuals or groups. Access rights can be granted or denied with different levels of scope on the object. Access rights can be defined on any of the following levels:

• Apply to the object as a whole, which applies to all properties of the object.

• Apply to a grouping of properties defined by property sets within the object.

• Apply to an individual property of the object.

Granting uniform read/write access to all properties of an object is the default access permission for the creator of the object. Granting or denying object access permissions to a property set is a convenient way to define permissions for a group of related properties. The grouping of properties is defined by the property set attribute of a property in the schema. The property set relationship can be customized by changing the schema. Finally, the definition of access rights on a per-property level provides the highest level of granularity of permissions. Definition of per-property access is available on all objects in the Active Directory.

Container objects in the directory also support fine-grain access with respect to who has permissions to create child objects and what type of child objects they may create. For example, the access control defined on an organizational unit (OU) can define who is allowed to create User objects (accounts) in this container. Another entry in the access control for the OU might define who is allowed to create Printer objects. Fine-grain access control on directory containers is an effective way to maintain organization of the directory name space.

A new implementation of the Access Control List (ACL) Editor, the common dialog control for viewing or changing object security permissions, provides an easy-to-use interface for defining access rights to Active Directory objects by property set or individual properties. The ACL Editor also supports defining inherited access rights on container objects that flow down to all subobjects in that portion of the directory tree.

Inheritance of Access Rights

Inheritance of access rights refers to how access control information defined at higher level containers of the directory flows down to subcontainers and leaf objects. There are generally two models for implementing inherited access rights: dynamic and static inheritance. Dynamic inheritance determines the effective access rights to an object by evaluating the permissions defined explicitly on the object and those defined for all parent objects in the directory. This allows flexibility to change access control on portions of the directory tree by making changes to a specific container that automatically affects all subcontainers and leaf objects. The trade-off to this flexibility is the performance cost to evaluate effective access rights at the time a client requests a read/write to a specific directory object.

Windows 2000 implements a static form of inheritance of access rights, referred to as Create Time inheritance. Access control information that flows down to child objects of the container can be defined. When the child object is created, the inherited rights from the container are merged with default access rights on the new object. Any changes to inherited access rights at higher levels in the tree must be propagated down to all affected child objects. New inherited access rights are propagated by the Active Directory to objects for which they apply, based on options for how the new rights are defined.

Performance for access control verification is very fast, using the static model of inheritance of access rights. Access checks are frequent and necessary operations that the operating system is designed to optimize—not just for directory object access, but also for the file system and all other Windows 2000 system objects.

Multiple Security Protocols

Windows 2000 supports multiple network security protocols because each protocol provides either compatibility for existing clients, more effective security mechanisms, or interoperability features for heterogeneous networks like the Internet. There are many authentication protocols in use in corporate networks today, and the Windows 2000 architecture does not limit which protocols can be supported. One security protocol to fit all needs would be simpler, but network configurations from small office networks to large-scale Internet content providers do not share the same security requirements. Customers need to have choices of how to integrate new security technology, such as dynamic passwords or public-key cryptography, into their computing environment.

Windows 2000 is designed to support multiple security protocols, an essential element for today's distributed computing environment. Using general-purpose Win32® security APIs, the operating system isolates supported applications from the details of different security protocols available. Higher-level application interfaces provided by Authenticated RPC and DCOM provide abstractions based on interface parameters to use security services.

The Windows 2000 security infrastructure supports these primary security protocols:

• Windows NT LAN Manager (NTLM) authentication protocol is used by Windows NT 4.0 and previous versions of Windows NT. NTLM will continue to be supported and used for pass-through network authentication, remote file access, and authenticated RPC connections to earlier versions of Windows NT.

• The Kerberos Version 5 authentication protocol replaces NTLM as the primary security protocol for access to resources within or across Windows 2000 domains. The Kerberos authentication protocol is a mature industry standard that has advantages for Windows network authentication. Some of the benefits of Kerberos protocol are mutual authentication of both client and server, reduced server load during connection establishment, and support for delegation of authorization from clients to servers through the use of proxy mechanisms.

• Distributed Password Authentication (DPA) is the shared secret authentication protocol used by some of the largest Internet membership organizations, such as MSN and CompuServe. This authentication protocol is part of Microsoft Commercial Internet System (MCIS) services and is specifically designed for users to use the same Internet membership password to connect to any number of Internet sites that are part of the same membership organization. The Internet content servers use the MCIS authentication service as a back end Internet service, and users can connect to multiple sites without reentering their passwords.

• Public-key-based protocols provide privacy and reliability over the Internet. SSL is the de facto standard today for connections between Internet browsers and Internet information servers. (A forthcoming IETF standard protocol definition based on SSL3 is currently known as the Transport Layer Security Protocol, or TLS.) These protocols, which use public-key certificates to authenticate clients and servers depend on a public-key infrastructure for widespread use. Windows NT 4.0 provides secure channel security services that implement the SSL/PCT protocols. Windows 2000 security has more enhanced feature support for public-key protocols, which are described later in this paper.

Enterprise security depends on having the flexibility to use the right security mechanisms when necessary. Enterprise computing will continue to depend on a wide range of network services provided by remote file and print servers, business application and data servers, and data warehouse and transaction processing environments. Support for multiple network security protocols allows Windows 2000 Professional and Windows 2000 Server to host a variety of network services in addition to Internet-based technologies.

The following diagram shows the architecture support for multiple security protocols implemented in Windows 2000 using the Security Support Provider Interface (SSPI).

Figure 4: Architecture for Multiple Authentication Services

The Security Support Provider Interface is a Win32 system API used by many applications and system services—for example, Internet Explorer (IE) and Internet Information Server (IIS)—to isolate application-level protocols from security protocols used for network authentication. Security providers use different credentials to authenticate the user, either shared-secret or public-key certificates. The security protocols interact with different authentication services and account information stores.

• NTLM security provider uses the MSV1_0 authentication service and NetLogon service on a domain controller for client authentication and authorization information.

• Kerberos security provider connects to an online Key Distribution Center (KDC) and the Active Directory account store for session tickets.

• DPA uses the MCIS security services for membership authentication and server-specific access information.

• Secure channel services are based on public-key certificates issued by trusted Certificate Authorities; they do not require an online authentication server.

The Windows security APIs for network authentication are defined by the Security Support Provider Interface (SSPI) documented in the Platform SDK. The SSPI communicates with a Win32 API based on the Generic Security Service Application Program Interface (GSS-API) and provides similar interface abstraction for security context management.1 Windows 2000 applications and services use SSPI to isolate application-level protocols from the details of network security protocols. Windows 2000 supports the SSPI interface to reduce application-level code needed to support multiple authentication protocols. SSPI provides a generic abstraction to support multiple authentication mechanisms based on shared-secret or public-key protocols. Applications using integrated Windows 2000 security take advantage of the modularity provided by SSPI by calling the SSPI routines directory or by using the higher-level network connection management protocols provided by authenticated RPC or DCOM.

Kerberos Authentication Protocol

The Kerberos authentication protocol defines the interactions between a client and a network Authentication Service known as a Key Distribution Center (KDC). Windows 2000 implements a KDC as the authentication service on each domain controller. The Windows 2000 domain is equivalent to a Kerberos realm but continues to be referred to as a domain. The Windows 2000 Kerberos implementation is based on the Internet RFC 1510 definition of the Kerberos protocol.2 The Kerberos client run time is implemented as a Windows 2000 security provider based on the SSPI. Initial Kerberos authentication is integrated with the WinLogon single-sign-on architecture. The Kerberos server (KDC), integrated with existing Windows security services running on the domain controller, uses the Active Directory as the account database for users (principals) and groups.

The Kerberos authentication protocol enhances the underlying security features of Windows 2000 and provides the following features:

• Faster server authentication performance during initial connection establishment. The application server does not have to connect to the domain controller to authenticate the client. This allows applications servers to scale better when handling large number of client connection requests.

• Delegation of authentication for multitier client/server application architectures. When a client connects to a server, the server impersonates the client on that system. But if the server needs to make a network connection to another back-end server to complete the client transaction, the Kerberos protocol allows delegation of authentication for the first server to connect on behalf of the client to another server. The delegation allows the second server to also impersonate the client.

• Transitive trust relationships for interdomain authentication. Users can authenticate to domains anywhere in the domain tree because the authentication services (KDCs) in each domain trust tickets issued by other KDCs in the tree. Transitive trust simplifies domain management for large networks with multiple domains.

The Kerberos version 5 authentication protocol defined in RFC 1510 has gone through a wide industry review and is well known in security interest groups.

Kerberos is a shared-secret authentication protocol because the user and the KDC both know the user's password or, in the case of the KDC, the one-way encrypted password. The Kerberos protocol defines a series of exchanges between clients, the KDC, and servers to obtain and use Kerberos tickets. When a user initiates a logon to Windows, the Kerberos SSP obtains an initial Kerberos ticket (TGT) based on an encrypted hash of the user's password. Windows 2000 stores the TGT in a ticket cache on the workstation associated with the user's logon context. When a client program attempts to access a network service, the Kerberos run-time checks the ticket cache for a valid session ticket to the server. If a ticket is not available, the TGT is sent in a request to the KDC for a session ticket that allows access to the server.

The session ticket is added to the ticket cache and may be reused for future connections to the same server until the ticket expires. The ticket expiration period is defined by domain security policy and is usually set for about eight hours. If the session ticket expires during the middle of an active session, the Kerberos security provider returns appropriate error values that allow the client and server to refresh the ticket, generate a new session key, and resume the connection.

The following diagram shows the relationship between the client, the KDC, and the application server using the Kerberos authentication protocol.

Figure 5: Kerberos authentication protocol overview

The Kerberos session ticket is presented to the remote service during the initial connection message. Portions of the session ticket are encrypted using a secret key shared between the service and the KDC. The server can quickly authenticate the client by verifying the session ticket without going to the authentication service because the Kerberos run time for the server has a cached copy of the server's secret key. Session connection setup is much faster on the server side than NTLM authentication. With NTLM, the server would obtain the user credentials, and then have to reauthenticate the user through the domain controller as part of establishing the connection.

Kerberos session tickets contain a unique session key created by the KDC to use for symmetric encryption of authentication information and data transferred between the client and server. In the Kerberos model, the KDC is used as an online trusted third party to generate the session key. Online authentication services are very efficient for distributed application services available in a campus-like network environment.

The Kerberos protocol is fully integrated with the Windows 2000 security architecture for authentication and access control. The initial Windows domain logon is provided by WinLogon. WinLogon uses the Kerberos security provider to obtain an initial Kerberos ticket. Other operating system components, such as the Redirector, use the SSPI interface to the Kerberos security provider to obtain a session ticket to connect to SMB Server for remote file access.

The Kerberos version 5 protocol defines an encrypted field in session tickets to carry Authorization Data, but use of the field is left to applications. Windows 2000 uses the Authorization Data in Kerberos tickets to carry Windows Security IDs representing the user and group membership. The Kerberos security provider on the server-side of a connection uses the Authorization Data to build a Windows security access token representing the user on that system. The server follows the Windows security model of impersonating the client—using the access token representing the client—before attempting to access local resources protected by Access Control Lists (ACLs).

Delegation of authentication is supported in the Kerberos version 5 protocol, using proxy and forwarding flags in session tickets. Windows 2000 uses the delegation feature to allow servers to obtain another session ticket to connect to remote servers on behalf of the client.

The Kerberos version 5 protocol is implemented for a variety of systems and is used to provide a single authentication service in a distributed network. Kerberos interoperability provides a common protocol that allows a single (possibly replicated) account database for authenticating users on all enterprise computing platforms to access all services in a heterogeneous environment. Kerberos interoperability is based on the following characteristics:

• A common authentication protocol used to identify the end user or service by principal name in a network connection.

• The ability to define trust relationships between Kerberos realms and to generate ticket referral requests between realms.

• Implementations that support the Interoperability Requirements defined in RFC 1510 regarding encryption, checksum algorithms, mutual authentication, and other ticket options.

• Support for Kerberos version 5 security token formats for context establishment and per-message exchange as defined by the IETF Common Authentication Technology working group.3

The principal name in a Kerberos ticket is used to authenticate the user's identity, but additional authorization information might be managed on the local system for access control. Identity-based authentication provides a high degree of interoperability for systems that support the Kerberos version 5 protocol; it does not, however, support user authorization. The Kerberos protocol provides for transport of authorization data, but the contents of this field are considered specific to the application service.

The Microsoft implementation of the Kerberos protocol supports the interoperability characteristics sufficient for identity-based authentication. In addition, Microsoft integrates authorization data in the form of Windows 2000 group memberships in Kerberos tickets to convey access control information to Windows 2000 services. The native representation of the authorization data is in Windows Security IDs.

Windows 2000 services have service accounts defined in the Active Directory, which defines the shared secret used by the KDC to encrypt session tickets. Clients attempting to connect to Windows 2000 services obtain session tickets to the target server from the KDC in the domain where the service account is defined. The Kerberos security provider supporting a Windows 2000 service expects to find Authorization Data in the session tickets that are used to build a security access token. The Windows 2000 service impersonates the security context of the client, based on the Authorization Data provided in the session ticket.

Clients that obtain initial Kerberos TGT tickets from KDCs on non-Windows 2000 systems use the Kerberos referral mechanism to request a session ticket from the KDC in the Windows 2000 Service domain. The referral ticket is created by inter-realm trust relationships between the KDCs. The ticket requests originating from an MIT Kerberos authentication service are not likely to contain authorization data. When session tickets do not contain authorization data, the Kerberos security provider on Windows 2000 tries to use the principal name in the ticket and create a security access token for a designated user account or use a default account defined for this purpose. Microsoft is still investigating some of the interoperability issues with different Kerberos configurations and will continue to work toward full Kerberos interoperability.

The DCE Security Services are also layered on the Kerberos protocol. DCE authentication services use RPC representation of Kerberos protocol messages. In addition, DCE uses the authorization data field in Kerberos tickets to convey Extended Privilege Attribute Certificates (EPACs) that define user identity and group membership. The DCE EPAC is used like Windows Security IDs for user authorization and access control. Windows 2000 services cannot translate DCE EPACs into Windows 2000 user and group identifiers. This is not a question of Kerberos interoperability, but of interoperability between DCE and Windows 2000 access control information. Microsoft will investigate ways to map DCE authorization to the Windows 2000 security model.

Windows 2000 also implements extensions to the Kerberos protocol to support authentication based on private/public-key pairs in addition to shared-secret keys. The public-key authentication extensions allow clients to request an initial TGT, using a private key, while the KDC verifies the request using the public-key obtained from an X.509 certificate stored in the User object in the Active Directory. The user's certificate could be issued by a third-party Certificate Authority, such as VeriSign's Digital IDs, or from the Microsoft Certificate Server in Windows 2000. After the initial private-key authentication, standard Kerberos protocols for obtaining session tickets are used to connect to network services.

A proposal to extend the Kerberos protocol specification to provide a method for using public-key cryptography for initial authentication has been submitted to the IETF working group for review. Microsoft is participating in the IETF standards process and intends to support the standard protocol extensions for public key.

Public-key authentication extensions to the Kerberos protocol provide a foundation for network authentication, using smart card technology. Windows 2000 allows users to log on to a workstation by using a smart card. In the future, there will be many options for obtaining certificates for end users, depending on their organization affiliations or job requirements. Windows 2000 provides a Certificate Server for organizations that want to issue public-key certificates to their users without depending on commercial CA services. The certificate policy is straightforward: Certificates are issued to users authenticated using valid domain account credentials. The next section describes how those certificates can be used for intranet and Internet access to resources on Windows 2000.

Internet Security for Windows 2000

Microsoft is developing a public-key security infrastructure to integrate public-key security with Windows 2000 security. Public-key cryptography is the security technology that enables strong security for enterprise and Internet communications. Microsoft Internet security technologies include a Certificate Server, a secure channel security provider that implements SSL/TLS protocols, the SET secure payment protocol for credit card transactions, and CryptoAPI components for certificate management and administration.

The components of the Microsoft public-key security infrastructure are shown below.

Figure 6: Microsoft public-key security components

The Microsoft Internet security infrastructure is based on industry standards for public-key security, including support for RSA Public-key Cipher, X.509 certificate formats, and PKCS standards.

The Windows NT 4.0 release provided the first components for using public-key security, including:

• CryptoAPI, with programmer support for key generation and exchange, digital signatures, and data encryption, using a provider architecture to support installable Cryptographic Service Providers.

• Crypto API support of X509 certificates and PKCS, which was released in Service Pack 3 for Windows NT 4.0 and is used by Internet Explorer 4.0 and Windows 2000.

• Secure Channel implementation of the Secure Sockets Layer (SSL) version 2.0, version 3.0 client-side support, and Private Communications Technology (PCT) version 1.0 public-key security protocols.

• Authenticode™, an industry-standard solution, using digital signatures to verify the integrity of software downloaded from the Internet and identification of the software publisher.

The Microsoft Internet security infrastructure builds on these components and provides additional functionality to support public-key security for Windows platforms, including Windows 2000. Many of the Internet security components are used by Microsoft Internet Explorer and Internet Information Server. The new features of the Microsoft Internet security infrastructure for Windows 2000 Distributed Security Services include:

• Client Authentication with SSL 3.0 based on public-key certificates.

• Certificate Server for issuing certificates to Windows 2000 domain accounts.

Windows 2000 security uses Internet standards for public-key security with features built into the operating system.

Secure Socket Layer and Transport Layer Security are public-key-based security protocols implemented by the Secure Channel (Schannel) security provider. These security protocols are used by Internet browsers and servers for mutual authentication, message integrity, and confidentiality. Authentication of the Internet server is performed by the Internet Explorer (the client) when the server's certificate is presented as part of the SSL/TLS secure channel establishment. The client program accepts the server's certificate by verifying the cryptographic signatures on the certificate, and any intermediate CA certificates, to one of several known or configured root CAs.

Client authentication is also supported by SSL 3.0 and TLS. Client authentication using public-key certificates is completed as part of the secure channel session establishment.

Figure 7 below shows the SSL 3.0 handshake messages between the client and server for secure connection establishment.

Figure 7: SSL 3.0 handshake

Authentication of the client by the server is the same process as server authentication. The server verifies the cryptographic signatures on the client's certificate, and any intermediate CA certificates, to a known or trusted root CA. However, once the identity of the client is verified through certificate verification (client authentication), the application server needs to establish a security context with appropriate access rights defined for the client. The access control information determines what resources the client is allowed to use on this server. In the Windows 2000 security architecture, access control is defined by the group memberships and privileges in the security access token.

Public-key client authentication uses the information in the client's certificate to map to local access control information. This mapping determines what authorization the client has to access resources on the server system. Initial support for client authentication by the Microsoft Internet Information Server is available by managing an authorization database to map certificate subject or issuer information to existing Windows 2000 accounts. The authorization database can be as simple or complicated as needed to meet the application requirements.

Windows 2000 provides broader support for client authentication by implementing a security service that uses the Active Directory to map certificate information to existing Windows accounts. The mapping can be performed using a search of the certificate subject name in the Windows directory or by searching for directory properties that identify the client certificate.

Windows 2000 support for client authentication integrates public-key certificates with the Windows 2000 security architecture. No separate database is required to define the access rights associated with public-key certificates. The access control information is maintained by the group membership stored in the Windows directory. Common Windows Directory Service administration tools are used for granting access rights by adding Windows users to groups.

Support for public-key certificate authentication in Windows 2000 allows client applications to connect to secure services on behalf of users who do not have a Windows 2000 domain account. Users who are authenticated based on a public-key certificate issued by a trusted Certificate Authority can be granted access to Windows 2000 resources. The Directory Service administration tools allow administrators, or delegated authorities, to associate one external user or more to an existing Windows 2000 account for access control. The Subject name in the X.509 Version 3 certificate is used to identify the external user that is associated with the account.

Businesses can share information securely to selected individuals from other organizations without having to create many individual Windows 2000 accounts. Many-to-one mapping of certificates to Windows 2000 user objects provides for strong authentication based on public-key certificates and common access control permissions. Client authentication of external users still requires the system administrator to configure the Certificate Authority for the external user's certificates as a trusted CA. This prevents someone with a certificate issued by an unknown authority from authenticating to the system as someone else.

The Microsoft Certificate Server, which is included with Windows 2000 and IIS 4.0, provides customizable services for issuing and managing certificates for applications using public-key cryptography. The Certificate Server can perform a central role in the management of such a system to provide secure communications across the Internet, corporate intranets, and other nonsecure networks. The Microsoft Certificate Server is customizable to support the application requirements of different organizations.

The Certificate Server receives requests for new certificates over transports such as RPC, HTTP, or e-mail. Each request is checked against custom or site-specific policies, sets optional properties of the certificate to be issued, and issues the certificate. It also allows administrators to add elements to a certificate revocation list (CRL), and publish a signed CRL on a regular basis. Programmable interfaces are included for use by developers to create support for additional transports, policies, certificate properties, and formats.

The policy module for the Certificate Server uses network authentication of certificate requests to issue certificates to users with Windows 2000 domain accounts. The policy module may be customized to meet the needs of the issuing organization. Certificate Server generates certificates in a standard X.509 format. Certificates in the X.509 format are commonly used to authenticate servers and clients involved in secure communications, using either the TLS or SSL protocols. The following sections describe uses of and some key features of Certificate Server.

On a corporate intranet or on the Internet, servers such as the Microsoft Internet Information Server can perform client authentication for secure communications using certificates generated by the Certificate Server. Certificate Server can also generate server certificates used by IIS and other Web servers to provide server authentication to assure clients (browsers) that they are communicating with the intended entity.

Windows NT 4.0 provided the low-level cryptography support and modular Cryptographic Service Providers in CryptoAPI. Windows 2000 benefits from the introduction of CryptoAPI Certificate Management to support public-key security.

Major new features of CryptoAPI include:

• Support for X.509 version 3 certificates and X.509 version 2.0 CRLs through common encoding/decoding functions, certificate parse, and verification.

• Support for PKCS #10 certificate requests and PKCS #7 for signed and enveloped data.

• Adding and retrieving certificates and CRLs from certificate stores, locating certificates by attributes and associating private keys.

• Digital signature and verification and data encryption support using higher-level functions available to applications in HTML, Java, Visual Basic® Scripting Edition (VBScript), and C/C++.

CryptoAPI features are used by Windows 2000 operating system components, such as the Software Publisher Trust Provider for Authenticode verification. Other applications and system services use CryptoAPI version 2.0 to provide the common functionality to enable public-key security technology.

Interbusiness Access: Distributed Partners

Internet-based enterprises are already doing business with customers and partners over the Internet. Resellers, suppliers, distributors, and anyone who is part of the extended business may connect to corporate intranets and access important company information. Employees and representatives in the field increasingly use local access to public networks, and then connect to remote corporate information sources. Windows NT security is evolving to support the changing needs of distributed computing over the Internet.

Interbusiness distributed computing is not limited to a single architecture, and the security technology should not limit business to a single way of accessing information. Many approaches are available as security technology rapidly changes. Windows 2000 integrates support for the security protocols and user models that fit application or business needs. More importantly, Windows 2000 provides a migration from the enterprise security in use today, with the opportunity to fully utilize Internet public-key security as the infrastructure matures.

Here are some of the options Windows 2000 security provides for managing and supporting interbusiness relationships:

• An initial approach widely used today is creating user accounts for business partners to access corporate information services. Integrating Windows 2000 security with the Active Directory makes management of these special accounts much easier. Organizational units in the directory can be used to group related accounts by partner, supplier, or other business relationship. Administration of these accounts can be delegated to the people in the organization who manage these partner relations. Virtual Private Networks are established between organizations to encrypt network traffic carried over the public network. Using this approach, business partners can use remote access services to get to corporate information in the same way as any other remote employee. Access to databases or information repositories can be controlled with Windows 2000 access control.

• Domain trust relationships are another tool for establishing cross-business relationships. The Active Directory provides much more flexibility to manage a tree of hierarchical domains. With Windows 2000 domain names integrated with DNS naming, Internet routing of information between two domains is easy to configure. If the business relationship requires it, domain trust can be used as one way to configure client/server applications that also have the privacy and integrity features necessary to communicate over the Internet. Users can use either Kerberos or public-key authentication protocols to access shared resources in remote domains.

• Organizations can use the Microsoft Internet security infrastructure to solve Internet security problems. Companies can issue public-key certificates to specific partners who need to access specific information resources. Instead of creating a user account or defining a domain trust relationship, certificates can be used as a way of providing user identification and authorization. Public-key certificates—and the infrastructure required to support issuing certificates and verifying certificate revocation—are the most effective ways to support business-to-business relationships over the Internet. Windows 2000 supports X.509 version 3 certificates issued by any certificate issuing system. System administrators on Windows 2000 define which Certificate Authorities are trusted. They can also associate external users authenticated by public-key certificates to Windows 2000 user accounts to define the access permissions associated with those users.

Enterprise and Internet Single Sign-on

Windows 2000 manages the user's network security credentials transparently after a single successful sign-on. The user is not concerned about whether a connection to a network server uses NTLM, Kerberos or a public-key-based security protocol. From the users' perspective, they have signed on to the system and now have access to a wide variety of network services.

Within the enterprise, access to resources is determined by the rights granted to users' accounts or by group memberships. Across the Internet, a user's access is based on their identity proven by a private-key signature operation and the corresponding public-key certificate. All of the security protocols rely on some form of user credentials, which are presented to a server when a connection is established. Windows 2000 manages these user credentials and automatically uses the appropriate set of credentials, based on the security protocol involved.

The Windows 2000 Active Directory supports multiple security credentials as part of the secure portion of user account information. These credentials are used for enterprise authentication services that use the domain controller for online user authentication. Advanced application servers can support integrated Windows 2000 authentication by using the Security Service Provider Interface for network authentication.

The NTLM authentication protocol is used by Windows 2000 clients to connect to servers running previous versions of Windows NT. For example, NTLM authentication is used to connect to a remote file share on a Windows NT 4.0 server or to connect a Windows NT 4.0 client to a Windows 2000 file share. NTLM credentials consist of the domain name, user name, and encrypted password entered once during the initial sign-on.

The security services on a domain controller manage a secure copy of the NTLM user credentials in the Active Directory to use for NTLM authentication. A Windows 2000 client manages the NTLM credentials entered at system sign-on on the client side to use when the client connects to Windows NT 4.0 servers using NTLM authentication. Support for NTLM credentials in the Windows 2000 security is the same as for Windows NT 4.0 for compatibility.

The primary authentication protocol for the Windows 2000 domain is Kerberos authentication. Kerberos credentials consist of the domain and user name (which could be in the form of Internet friendly names, such as BobbyB@microsoft.com), and the Kerberos-style encrypted password. When the user signs on to the system, Windows 2000 obtains one or more Kerberos tickets to connect to network services. The Kerberos tickets represent a user's network credentials in Kerberos-based authentication.

Windows 2000 automatically manages the Kerberos ticket cache for connections to all network services. Tickets have an expiration time and occasionally need to be renewed. Ticket expiration and renewal are handled by the Kerberos security provider and associated application services. Most services, such as the file system Redirector, automatically keep session tickets up-to-date. Regular ticket renewal gives added session security by changing the session keys periodically.

Internet credentials in the form of private/public-key pairs and certificates are managed by the user. The Active Directory is used to publish public-key certificates for users, and standard directory access protocols are used to locate them. Private keys and certificates issued to end users are kept in secure storage, either on the local system or on a smart card. The secure storage is provided with the Internet security technologies and is known as a Protected Store.

The implementation of the Protected Store is based on the CryptoAPI architecture for Windows NT. CryptoAPI provides key management functionality and other cryptographic capabilities for building a secure store, with certificates kept in a Certificate Store. The Windows 2000 implementation of public-key-based security protocols uses keys and certificates accessed from the Protected Store and Certificate Store as user credentials for accessing Internet-based servers. In many cases, user-defined properties of certificates in the Certificate Store allow the security protocols to automatically select and use the correct certificate and signature key. Advances in Internet security protocols (SSL3/TLS) allow a server to request specific credentials from the client that are used automatically from the Certificate Store if they are available.

The information in the Protected Store and Certificate Store is available to roaming users because they are implemented securely as part of the user's profile. When a user initially logs on to the Windows client, the user's profile information is copied to that computer. If the user gets new keys and certificates during that session, the user profile is updated to the central server when the user logs off.

The transition from the NTLM authentication used in Windows NT 4.0 (and previous versions of Windows NT) to Kerberos domain authentication will be very smooth. Windows 2000 services supports client or server connections using either security protocol. Security negotiation, either by the SSPI layer or the application protocol, provides another option to select the best match from available security protocol options.

The transition from enterprise-based services using Kerberos authentication to Internet-based services using public-key authentication is completely transparent to the user. Windows 2000 support for multiple user credentials makes it possible to use secret-key authentication technology for enterprise application services with very high performance and public-key security technology when connecting to Internet-based servers. Most application protocols, such as LDAP, HTTP/HTTPS, or RPC, support authentication, and they are designed to support multiple authentication services and select those services during connection establishment.

Rather than relying on a single authentication technology and a single authentication protocol, Windows 2000 uses multiple protocols as needed to fit the application and user-community requirements for secure network computing.

Providing a Smooth Migration to Next-Generation Domains

Migrating from a Windows NT 4.0 environment to the Windows 2000 domain is easy because of backward compatibility with existing Windows security and account replication protocols. A smooth migration is available because Windows 2000 has the following interoperability features:

• A Windows 2000 domain controller can play the role of a Windows NT 4.0 BDC and receive domain account replication from an existing Windows NT 4.0 PDC.

• Windows NT 4.0 workstations can send network authentication requests using the NTLM authentication protocol to a Windows 2000 domain controller, acting as a BDC in the Windows NT 4.0 domain.

• Windows 2000 domain controllers can establish trust relationships with Windows NT 4.0 domains and support pass-through authentication between domains. This means that not all domains in an enterprise are required to upgrade to the Windows 2000 domain security at the same time.

Windows 2000 domain controllers can eventually replace Windows NT 4.0 domain controllers in a gradual upgrade of Windows NT 4.0 BDCs to Windows 2000 domain controllers. Windows NT 4.0 account management tools are used on the primary domain controller as long as the PDC is running Windows NT 4.0. Eventually, all domain controllers can be upgraded to use the Active Directory for account management and multimaster account replication.

Windows 2000 support for multiple authentication protocols means that from a single domain logon at the desktop, users can access Windows 2000 services anywhere in a mixed domain environment, including:

• A Windows 2000 server in the logon, or home domain, using Kerberos session tickets issued by the Key Distribution Center (KDC) on the domain controller.

• A Windows 2000 server in a trusted domain, using a Kerberos referral to the KDC in the trusted domain, to issue a session ticket to the remote server.

• Or, a Windows NT 4.0 server in a trusted domain using NTLM pass-through authentication between the client, the Windows NT 4.0 server, and the trusted domain controller.

Because Windows 2000 continues to support NTLM authentication, Windows NT 4.0 clients who do not use Kerberos authentication can also connect to Windows 2000 application servers.

These interoperability features allow flexibility for organizations to plan and implement a migration strategy to Windows 2000 Servers to better fit their growing business needs.

Summary

The Windows 2000 Distributed Security Services provides flexible solutions for building secure, scalable distributed applications. Security administration and management have richer features for delegation and fine-grain account control. The Active Directory supports domains with a much higher number of accounts in a structured naming environment of organizational units. Interdomain trust management is simpler, providing greater flexibility to use domains in ways that reflect the needs of the enterprise.

Windows security APIs for network authentication, data privacy, digital signatures, and encryption support secure application development for the enterprise and the Internet. The SSPI and CryptoAPI interfaces, as well as higher-level COM and DCOM interface abstractions, make all the integrated security features of Windows 2000 available for applications to use. The robust security architecture of Windows NT is used consistently across all system components and will be extended to support strong authentication and public-key security. These features are unmatched by any other distributed application platform available today.

Windows 2000 Distributed Security integrates mature Internet standards for authentication while introducing new public-key security technology based on industry direction and available standards. Many of the Internet public-key security standards are still forming. Microsoft is involved in the development of these standards but recognizes that they are likely to change over time. The Windows 2000 security architecture is specifically designed to incorporate new security technology in the form of protocols, cryptographic service providers, or third-party authentication technology. Customers deploying Windows 2000 have choices about what security technology to use, how to integrate security into their application environment with minimum impact, and when to migrate to new technology as it becomes available.

Together, all these make the Windows 2000 Distributed Security Services the best foundation for secure Internet-distributed computing.

1 "Generic Security Services Application Program Interface", J. Linn, Internet RFC 1508, September, 1993.

2 "The Kerberos Network Authentication Service (V5)", J. Kohl and C. Neumann, Internet RFC 1510, September, 1993.

3 RFC 1964 defines the Kerberos Version 5 GSS-API Mechanism security token formats.