Windows NT® Server
Server Operating System
White Paper
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 NT security. To meet these expanding needs, Microsoft is developing the Windows NT Distributed Security Services.
This White Paper examines the components of the Windows NT Distributed Security Services, and provides details on their implementation.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, BackOffice, the BackOffice logo, Visual Basic, Win32, Windows, and Windows NT are registered trademarks and ActiveX and Authenticode are trademarks of Microsoft Corporation.
Java is a trademark of Sun Microsystems, Inc.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
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 in order to support 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 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, the 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 the Enterprise network, the intranet, 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 for the user, excellent administration tools, and a solid security infrastructure that supports both the Enterprise and the Internet.
Windows NT 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 NT 5.0 Distributed Security Services include:
This White Paper describes the next generation of Windows NT-distributed security, which provides features to support the demands of the Internet-based Enterprise. Most of the material described here is delivered in Windows NT 5.0, though some features have already been implemented in Windows NT 4.0, as noted in the text.
There are many areas in which Windows NT security will change to support the Internet-based Enterprise. Some of the changes reflect advances in supporting large organizations through the use of the hierarchical Windows NT Active Directory. Other changes take advantage of the flexibility of the Windows NT security architecture to integrate authentication using Internet public-key certificates.
The list below introduces the new Windows NT security features:
In addition to these changes, we expect third parties to host dynamic password authentication services on Windows NT Server and to integrate dynamic passwords with Windows NT domain authentication. The APIs and documentation to support these third-party products are available in the Win32® SDK for Windows NT 4.0.
Each of the new features of Windows NT security is described in more detail in the following sections.
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 NT 5.0 distributed security services use Windows NT 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 NT domains, and the hierarchical name context within each domain using Organizational Units (OUs) as directory object containers.
Figure 1: Hierarchical structure of the Windows NT Active Directory
The advantages of integrating security account management with the Windows NT Active Directory are:
Storing the security account information in the Windows NT Active Directory means 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 Security Services integrated into the Windows NT 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 NT operating system implements the 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 required to read or update the object properties.
The diagram below shows the fundamental relationship between Active Directory and operating system security services.
Figure 2: Relationship between Directory and Security Services
The Active Directory uses impersonation and Windows NT access verification to determine if an Active Directory client request 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 NT security model provides a unified and consistent implementation of access control to all domain resources based on group membership. Windows NT security components can trust the security related information stored in the directory. For example, the Windows NT 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 NT operating system, and is not otherwise available.
The Windows NT 5.0 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 Windows NT 5.0 Active Directory supports two forms of trust relationships:
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 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 will 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:
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 Windows NT Active Directory provides real benefits to manage the 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.
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 NT 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:
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 Windows NT 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 refers to how access control information defined at higher level containers of the directory flow 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 NT implements a static form of inheritance of access rights, referred to as Create Time inheritance. Access control information can be defined on containers that will flow down to child objects of the container. When the child object is created, the inherited rights from the container are merged with default access rights on the new object. Any future 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 for the file system and all other Windows NT system objects.
Windows NT supports multiple network security protocols because each protocol provides either compatibility for existing clients, stronger, 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 NT 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 for how to integrate new security technology, such as dynamic passwords or public-key cryptography, into their computing environment.
Windows NT is designed to support multiple security protocols, an essential element for today’s distributed computing environment. Using general purpose Win 32 security APIs, supported applications are isolated from the details of different security protocols available. Higher-level application interfaces provided by Authenticated RPC and DCOM provide abstractions to use security services based on interface parameters.
The Windows NT 5.0 security infrastructure supports these primary security protocols:
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 NT Workstation and Windows NT 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 NT 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.
The Windows NT security APIs for network authentication are defined by the Security Support Provider Interface (SSPI) documented in the Win32 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. Windows NT applications and services use SSPI to isolate application-level protocols from the details of network security protocols. Windows NT 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 NT 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.
The Kerberos authentication protocol defines the interactions between a client and a network Authentication Service known as a Key Distribution Center (KDC). Windows NT implements a KDC as the authentication service on each Domain Controller. The Windows NT domain is equivalent to a Kerberos realm but will continue to be referred to as a domain. The Windows NT Kerberos implementation is based on the Internet RFC 1510 definition of the Kerberos protocol. The Kerberos client run time is implemented as a Windows NT 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 NT security services running on the Domain Controller, uses the Windows NT Active Directory as the account database for users (principals) and groups.
The Kerberos authentication protocol enhances the underlying security features of Windows NT and provides the following features:
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 NT (and Windows® 95 clients as well), the Kerberos SSP obtains an initial Kerberos ticket (TGT) based on an encrypted hash of the user’s password. Windows NT 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 codes 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 using NTLM authentication is. 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 NT security architecture for authentication and access control. The initial Windows NT 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 up to applications. Windows NT uses the Authorization Data in Kerberos tickets to carry Windows NT 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 NT security access token representing the user on that system. The server follows the Windows NT 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 NT 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:
The principal name in a Kerberos ticket is used to authenticate the user’s identity while 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.
Microsoft’s 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 NT group memberships in Kerberos tickets to convey access control information to Windows NT services. The native representation of the authorization data is Windows NT Security IDs.
Windows NT services have services accounts defined in the Windows NT Active Directory, which defines the shared secret used by the KDC to encrypt session tickets. Clients attempting to connect to Windows NT 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 NT service will expect to find Authorization Data in the session tickets used to build a security access token. The Windows NT service will impersonate 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 NT systems will use the Kerberos referral mechanism to request a session ticket from the KDC in the Windows NT 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 NT will try 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 to find solutions for 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 in a similar manner as Windows NT Security IDs for user authorization and access control. Windows NT services will not be able to translate DCE EPACs into Windows NT user and group identifiers. This is not an issue with Kerberos interoperability, but an issue of interoperability between DCE and Windows NT access control information. In the future, Microsoft will investigate ways to map DCE authorization to the Windows NT security model.
Windows NT will also implement 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 Windows NT 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 NT. 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 NT 5.0 lets users log on to the Windows NT workstation 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 NT will provide 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 NT.
Microsoft is developing a public-key security infrastructure to integrate public-key security with Windows NT security. Public-key cryptography is the security technology that enables strong security for Enterprise and Internet communications. Microsoft’s 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 Microsoft’s public-key security infrastructure are shown below.
Figure 6: Microsoft’s Public-key Security Components
Microsoft’s 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:
Microsoft’s Internet security infrastructure builds on these components and provides additional functionality to support public-key security for Windows platforms, including Windows NT. Many of the Internet security components are used by Microsoft’s Internet Explorer and Internet Information Server. The new features of Microsoft’s Internet security infrastructure for the next generation of Windows NT Distributed Security Services include:
Windows NT 5.0 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 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 NT 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 Microsoft’s Internet Information Server will be available by managing an authorization database to map certificate subject or issuer information to existing Windows NT accounts. The authorization database can be as simple or complicated as needed to meet the application requirements.
The next release of Windows NT provides broader support for client authentication by implementing a security service that uses the Windows NT Active Directory to map certificate information to existing Windows NT accounts. The mapping can be performed using a search of the certificate subject name in the Windows NT directory, or searching for directory properties that identify the client certificate.
Windows NT support for client authentication integrates public-key certificates with the Windows NT 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 NT directory. Common Windows NT Directory Service administration tools are used for granting access rights by adding Windows NT users to groups.
Support for public-key certificate authentication in Windows NT allows client applications to connect to secure services on behalf of users who do not have a Windows NT domain account. Users who are authenticated based on a public-key certificate issued by a trusted Certificate Authority can be granted access to Windows NT resources. The Directory Service administration tools allow administrators, or delegated authorities, to associate one external user or more to an existing Windows NT 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 in a secure manner to selected individuals from other organizations without having to create many individual Windows NT accounts. Many-to-one mapping of certificates to Windows NT 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 will be included with Windows NT 5.0 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 in order 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 NT 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 Microsoft’s 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 in order 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 NT 5.0 benefits from the introduction of CryptoAPI Certificate Management to support public-key security.
Major new features of CryptoAPI include:
The CryptoAPI features are used by Windows NT operating system components such as the Software Publisher Trust Provider for Authenticode verification. Other applications and system services will use CryptoAPI Version 2.0 to provide the common functionality to enable public-key security technology.
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 NT has integrated support for the security protocols and user models that fit application or business needs. More importantly, Windows NT provides a migration from Enterprise security in use today, with the opportunity to leverage Internet public-key security as the infrastructure matures.
Here are some of the options Windows NT security provides for managing and supporting interbusiness relationships:
Windows NT manages the user’s network security credentials transparently after a single successful logon. The user is not concerned whether a connection to a network server uses NTLM, Kerberos, or a public-key-based security protocol. From the user’s perspective, they have logged 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 at connection establishment. Windows NT manages these user credentials and automatically uses the appropriate set of credentials based on the security protocol involved.
The Windows NT 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 NT authentication by using the Security Service Provider Interface for network authentication.
The NTLM authentication protocol is used by Windows NT 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 NT 5.0 file share. NTLM credentials consist of the domain name, user name, and encrypted password entered once during the initial logon to Windows NT.
The security services on a domain controller manage a secure copy of the NTLM user credentials in the Windows NT Active Directory to use for NTLM authentication. A Windows NT 5.0 Workstation or client manages the NTLM credentials entered at system logon 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 NT 5.0 security is the same as for Windows NT 4.0 for compatibility.
The primary authentication protocol for the Windows NT 5.0 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 logs on to the system, Windows NT 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 NT 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, will 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 Windows NT 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 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 Microsoft’s CryptoAPI architecture for Windows NT. CryptoAPI provides key management functionality and other cryptographic functionality for building a secure store, with certificates kept in a Certificate Store. The Windows NT implementation of public-key-based security protocols will use 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 will automatically be used from the Certificate Store if they are available.
The information in the Protected Store and Certificate Store will be available to roaming users because they will be implemented securely as part of the user’s profile. When a user initially logs on to the Windows NT Workstation, the user’s profile information will be copied down to that computer. And if the user gets new keys and certificates during that session, their profile is updated up to the central server when they log 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 NT services can support 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 NT 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 NT will use multiple protocols as needed to fit the application and user-community requirements for secure network computing.
Migrating from a Windows NT 4.0 environment to the Windows NT 5.0 domain will be easy because of backward compatibility with existing Windows NT security and account replication protocols. A smooth migration is available because Windows NT has the following interoperability features:
Windows NT 5.0 Domain Controllers can eventually replace Windows NT 4.0 domain controllers in a gradual upgrade of Windows NT 4.0 BDCs to Windows NT 5.0 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 Windows NT Active Directory for account management and multimaster account replication.
Windows NT support for multiple authentication protocols means that from a single domain logon at the desktop, users can access Windows NT services anywhere in a mixed domain environment, including:
Because Windows NT will continue to support NTLM authentication, Windows NT 4.0 clients who do not use Kerberos authentication will also be able to connect to Windows NT 5.0 application servers.
These interoperability features allow flexibility for organizations to plan and implement a migration strategy to the Windows NT 5.0 Servers to better fit their growing business needs.
The Windows NT 5.0 Distributed Security Services provides flexible solutions for building secure, scaleable distributed applications. Security administration and management will have richer features for delegation and fine-grain account control. The Windows NT 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 NT 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 NT 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 NT Distributed Security integrates mature Internet standards for authentication while at the same time 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 they are likely to change over time. The Windows NT 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 NT 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 makes the Windows NT 5.0 Distributed Security Services the best foundation for secure Internet-distributed computing.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
For more information about the Windows NT 5.0 Active Directory, see the companion White Paper, Microsoft Windows NT Active Directory Technical Summary.
Additional information on Microsoft’s Internet security is available at Microsoft’s Web site at http://www.microsoft.com/security.
Additional information on the Windows NT security architecture, Security Support Provider Interface, CryptoAPI, and Windows NT security APIs is available in the online references for the Win32 Software Developers Kit.