Single Sign-On in Windows 2000 Networks

Abstract

Single Sign-on (SSO) allows enterprise network users to seamlessly access all authorized network resources, on the basis of a single authentication that is performed when they initially access the network. SSO can improve the productivity of network users, reduce the cost of network operations, and improve network security.

Microsoft Windows® 2000 operating system provides an integrated, comprehensive and easy-to-use SSO capability. SSO is provided natively in Windows 2000 by means of the built-in Kerberos and Secure Sockets Layer protocols, which also can provide standards-based SSO within mixed networks. Microsoft SNA Server further extends this capability to mainframe environments by means of their proprietary protocols. Homogeneous Windows 2000 based networks enjoy the most easily managed, most seamless SSO capability, but because of its broad interoperability, Windows 2000 also is the best choice as an SSO intermediary between disparate systems in a heterogeneous network.

On This Page

Introduction
SSO within Windows 2000 Domains
SSO Within Heterogeneous Networks
Summary
Additional Information

Introduction

Single Sign-on (SSO) is the ability of a user to authenticate him- or herself that is, to prove his or her identity to a network one time, and thereafter to have access to all authorized network resources without additional authentication. The network resources in question can range from printers and other hardware, to applications, to files and other data, all of which may be spread throughout an enterprise on servers of various types that may be running different operating systems.

Microsoft provides an integrated, comprehensive, easy-to-use SSO capability as part of the Windows 2000 operating system, thus allowing dramatic reduction in the total cost of ownership (TCO) for a computing enterprise by improving user and administrator productivity while improving security. The greatest benefits are derived from implementing Windows 2000 homogeneous domains, but customers can derive significant benefits even when deploying Windows 2000 in heterogeneous networks. Furthermore, because SSO for Windows 2000 interoperates with so many other vendors' operating systems, it is the best choice to serve as an SSO hub in heterogeneous networks.

Specifically, customers who implement SSO via Windows 2000 can expect the following benefits:

• Simpler administration. The primary barrier to adoption for most SSO implementations is that they are bolted onto the operating system and add to the administrator's burden by requiring him or her to perform SSO-specific tasks, using SSO-specific tools. However, under Windows 2000, SSO-related tasks are performed transparently as part of normal maintenance, using the same tools that are used for other administrative tasks.

• Better administrative control. All network management information in Windows 2000, including all SSO-specific information, is stored in a single repository, Active Directory® directory service. This means that there is a single, authoritative listing of each user's rights and privileges. This enables the administrator to change a user's privileges and know that the results will propagate network wide.

• Improved user productivity. Users are no longer bogged down by multiple logons, nor are they required to remember multiple passwords in order to access network resources. This is also a benefit to help desk personnel, who need to field fewer requests for forgotten passwords.

• Better network security. All SSO methods available under Windows 2000 provide secure authentication and provide a basis for encrypting the user's session with the network resource. Eliminating multiple passwords also reduces a common source of security breaches—users writing down their passwords. Finally, because of the consolidation of network management information within Active Directory, the administrator can know with certainty that when she disables a user's account, the account is fully disabled.

• Consolidation of heterogeneous networks. By joining disparate networks, administrative efforts can be consolidated, ensuring that administrative best practices and corporate security policies are being consistently enforced.

SSO within Windows 2000 Domains

SSO is provided natively within Windows 2000 domains by means of the Kerberos authentication protocol, which is the default authentication protocol used in Windows 2000. The use of the Kerberos protocol provides significant improvements in administrative ease, security, and network performance.

The Kerberos protocol is based upon the idea of tickets, encrypted data packets issued by a trusted authority called a Key Distribution Center (KDC). A ticket vouches for a user's identity, as well as carrying other information. A KDC provides tickets for all of the users in its area of authority, or realm. In Windows 2000, every domain controller is a KDC, and the realm of a domain controller corresponds to its domain. For detailed information on the Kerberos protocol, see Microsoft's white paper, Microsoft Windows NT Distributed Security Services: Secure Networking using Windows NT Server Distributed Services Technology Preview.

The operation of the protocol is simple, as shown in Figure 1. At logon time, the user authenticates to a KDC, which provides it with an initial ticket called a Ticket Granting Ticket (TGT). When the user needs to use a network resource, his user session presents the TGT to the domain controller and requests a ticket for the particular resource, called a Service Ticket (ST). He presents the ST to the resource, which grants him access.

Figure 1: Basic Transactions in the Kerberos Protocol

Seamless Integration

The integration of the Kerberos protocol into the Windows 2000 administrative and security model provides simple, effective management and control of users and network resources. A frequent complaint about previous Kerberos implementations is that they are adjuncts to the operating system rather than integrated into it. The Kerberos software operates atop the operating system's normal security architecture rather than as a part of it, requiring SSO-specific information to be stored separately from other system information and forcing the administrator to learn additional administrative tools solely for the purpose managing the SSO infrastructure.

However, the Kerberos protocol is fully integrated into Windows 2000. Kerberos is an inherent part of the Windows 2000 security architecture; indeed, it is the default authentication method. SSO-related information is stored in Active Directory along with all other information about network objects. Finally, the Kerberos model is integrated into the Windows 2000 domain model.

Trust relationships between domains in effect introduce the domain controllers, the Kerberos KDCs, in the two domains. As shown later in this article, when a user in one domain needs access to a resource in a trusting domain, the user's domain controller services his request for a ticket by making a cross-realm referral to the domain controller that owns the resource. This domain controller trusts the referral, and issues a ticket to the user. This integration is one key reason why Windows 2000-based networks can scale to very large sizes while retaining local control over local resources. By default, all domains within a Windows 2000 domain tree trust each other and accept referrals from each other. Forests in Windows 2000 do not trust each other by default, but trust relationships can easily be established between them.

Figure 2: Cross-Realm Referrals

Simple Administration

In a homogeneous Windows 2000–based network, the administrator never has to perform SSO-specific administrative tasks. Instead, SSO functions are integrated into the administrative tasks that he or she already performs. For example, the administrator never has to establish the cryptographic keys that the user and domain controller share. When he or she creates the user account, the shared keys are transparently generated as part of the process of creating the account, and are securely disseminated where needed. Similarly, when the administrator establishes trust relationships between domains, the keys needed to affect cross-realm referrals are transparently generated and securely exchanged.

Administrative tasks can be easily carried out using the Microsoft Management Console (MMC), which provides a common framework for all administrative tools. Each tool is packaged as a snap-in module, and the MMC provides a common user experience and usage paradigm. All SSO administrative functions are carried out via MMC snap-ins like the Active Directory Manager, shown in Figure 3.

Figure 3: Active Directory Manager

Administrators also benefit from Microsoft's use of standards-allowable extensions to the Kerberos protocol that enable the tickets to carry authorization information. Most Kerberos implementations carry only authentication information, so, after using the ticket to establish the user's identity, the network resource must consult a local database to determine what the user is allowed to do. Constructing and maintaining these databases adds to the administrative burden and complexity of administering the network. However, in Windows 2000, none of these local databases are needed. All authorization information is centrally stored within Active Directory, and when a user requests a ticket, Windows 2000 packages the information within the Kerberos ticket in the form of a Security Access Token (SAT). This significantly reduces the complexity involved in managing the network.

Better Network Performance

The use of the Kerberos protocol in Windows 2000 allows significant improvements to be realized in network performance by removing the domain controller as a bottleneck in authenticating users to network resources. In most network authentication protocols, the network's security authority must provide authentication for every use of a network resource. For example, in previous versions of Microsoft Windows NT® operating system, a domain controller had to vouch for a user's identity every time he or she wanted to use a printer, even if it was the same printer he or she had used just minutes before.

However, this bottleneck is eliminated in Windows 2000, as shown below. When a user needs access to a network resource for the first time, his user session asks the domain controller for a ticket. The domain controller's sole participation in the use of the resource is to issue the ticket to the user's session. When the user subsequently wants to use the same resource, the domain controller is not involved at all, because the tickets are reusable until they expire1. Tickets are stored in a local cache that is part of the security architecture's protected storage, and when one is needed, the user's session simply retrieves the ticket from the cache and presents it to the resource.

Figure 4: Comparison of NTLM and Kerberos Authentication

Network performance can be further improved by the judicious use of trust relationships between the domains in an Active Directory tree. As noted above, all domains within a tree trust each other by default. The chain of cross-realm referrals follows the structure of the domain tree. In a complex tree like the one shown below, many referrals could be needed for a user to obtain a ticket to use a resource on a widely separated domain. However, a shortcut trust allows two domains to establish a direct referral between them, regardless of the domain tree topology.

Figure 5: Shortcut Trusts Improve Network Performance

Improved Security

The use of the Kerberos protocol in Windows 2000 provides several important improvements in network security. First, it allows mutual authentication. Both the user and the network resource can verify that they are not talking to an imposter. Parts of the ticket are encrypted using a key that only the user and the domain controller share, and other parts are encrypted using a key that only the network resource and the domain controller share. The fact that each can read its part of the ticket proves that each is who they say they are.

Second, it allows encryption of user sessions to be transparently and automatically performed. Windows 2000 includes the Internet Protocol Security (IPSEC) protocol as part of its security architecture. IPSEC can automatically initiate encryption of a user's session with a network resource as a matter of policy, using cryptographic key material that is carried within the Kerberos ticket. For example, a corporation might decide that it wants to protect employees' retirement fund information. It could establish a policy that automatically initiates IPSEC encryption whenever a user accesses the human resource server.

Finally, Kerberos tickets can be delegated, allowing improved auditing and control in multitiered applications. In a multitier application, the user requests a service from the user interface layer, which passes the request to a middle tier that applies business logic and generates database commands to fulfill the user's request. Traditionally, the middle tier and the database both operate in the security context of the operating system. This places the full responsibility for access control upon the user interface tier. It also makes it difficult or impossible to use the audit logs to tell which database requests were made for which users, since the audit information from the middle and back tiers indicate that every request was made by the operating system.

However, under Windows 2000, the user places a request with the user interface layer and provides a ticket as authentication. The user interface layer uses the ticket to represent itself as the user to the middle layer, which in turn uses the ticket to represent itself as the user when requesting service from the database. This process, known as impersonation, allows each layer to know exactly who is requesting a service and to perform access control as needed; it also allows the system audit records to show exactly who each action was performed for.

Figure 6: Authentication that can be delegated improves Access Control and Auditing in a Multitiered Application

Widespread Availability

With the release of Windows 2000, all system services and all BackOffice family products will adopt Kerberos as the default authentication method. Likewise, all third-party products that carry the BackOffice logo will also use Kerberos as the default authentication. Developers can easily implement Kerberos authentication within new or existing applications by means of the Security Support Providers Interface (SSPI), an application-programming interface that provides the security services of Windows 2000, including Kerberos authentication services.

To provide backward compatibility with previous versions of Windows NT and with legacy applications, Windows 2000 will continue to support the NTLM authentication protocol. This will allow customers to deploy Windows 2000 within existing Windows NT–based networks, without needing to do a rip-and-replace upgrade. Windows 2000 uses Kerberos as the default authentication method, but also will participate in NTLM authentication as needed. This enables customers to gracefully transition from previous versions of Windows NT to Windows 2000; when the last down-level computer is upgraded, the network can enjoy the full benefits of Windows 2000 features.

SSO Within Heterogeneous Networks

Microsoft provides the flexibility to support SSO within a network comprised of a variety of vendors' platforms, via its support for standards-based authentication protocols and Microsoft gateway products. This allows enterprise customers to extend the benefits of SSO to their entire network, and establishes Windows 2000 as one of the best platforms to act as a mediator between disparate systems.

Figure 7: SSO Interoperability within Heterogeneous Networks

Providing SSO within a heterogeneous environment brings similar benefits in terms of total cost of ownership as it does in a Windows 2000 homogeneous case. Enterprises can share existing resources between all users of the network, rather than having to provide duplicate resources on every disparate system they use. User productivity also is improved in a similar manner as in a Windows 2000 homogeneous domain. Users can easily navigate through the corporate network without needing to know when they have crossed the boundary from one platform to another. Security is improved by providing for mutual authentication of clients and servers, and by removing the temptation for users to write down their multiple passwords. Because these benefits are associated with SSO in general, we will not reiterate them in the sections below; instead, we will focus on the SSO benefits that are unique to each case.

SSO Via Kerberos Interoperability

Microsoft's implementation of the Kerberos protocol in Windows 2000 is fully compliant with the IETF Kerberos version 5 specification. This allows Windows 2000 domains to seamlessly interoperate with standards-compliant third-party Kerberos implementations such as CyberSafe's TrustBroker, thereby allowing SSO between Windows 2000 and networks running the Apple Macintosh, AIX, Digital Unix, HP-UX, IRIX, Netware, Solaris, SunOS, Tandem, and MVS/ESA operating systems.

Simple Integration of Networks

Establishing a trust relationship between Windows 2000 and disparate networks using Kerberos is simple. The administrator establishes a trust relationship between the KDCs in the different realms, and tickets are provided via cross-realm referrals. The administrator of Windows 2000 sets up a user account to which the incoming users will be mapped. Once this has been done, the rights and privileges of incoming users are managed via their Windows 2000-based user accounts, using the same administrative tools as are used for native Windows 2000 users.

Cross-realm referrals in a heterogeneous environment are similar to those previously discussed for homogeneous Windows 2000 networks (see Figure 2). When a user on the other system needs to access a network resource in the Windows 2000 domain, his user session requests a ticket for the resource. The KDC, seeing that the resource lies in the Windows 2000 domain, refers the user to the Windows 2000 domain controller and vouches for his identity. The Windows 2000 domain controller then maps the user's identity to the corresponding Windows 2000 user account and issues the ticket to the user, who presents the ticket to the resource. For a Windows 2000 user who needs to use a resource in the other system, the process happens in reverse, although the administrative procedures that are used on the other system will vary.

It must be pointed out that working in a heterogeneous environment does introduce an unavoidable loss of administrative simplicity as compared to a Windows 2000-based homogeneous network. Some administrative actions that happen transparently under Windows 2000 must be performed manually when joining heterogeneous networks. For example, in contrast to Windows 2000, when trust is established in a heterogeneous environment, the administrator must manually synchronize keys between the Windows 2000 domain controller and the other system's KDC. Likewise, the administrator loses the advantage of having a single set of administrative tools and a single repository of SSO-related information. Instead, there is at best a single set of tools for each platform, and a single repository of SSO-related information for each platform. However, the ability to allow seamless sharing of resources is clearly a boon to enterprise customers, and frequently is worth the additional administrative burden.

Improved Security

Providing SSO via Kerberos interoperability significantly improves security by providing a lingua franca for the exchange of security information. Operating systems rarely share a common authentication protocol, and as a result, when user ids and passwords are exchanged between disparate systems, they usually are sent as plain text. However, Kerberos tickets are encrypted, providing a mechanism for securely exchanging authentication information. Similarly, because Kerberos tickets contain cryptographic key information, they provide a secure key exchange mechanism for establishing encrypted sessions between the platforms.

Finally, the trust relationship between KDCs, as the channel through which all user authentication information is exchanged, provides a simple and effective way to control resource sharing. For example, if two departments in a company, one running under Windows 2000 and one running under another system, allow resource sharing via Kerberos-based SSO, it is easy to temporarily disallow the sharing simply by removing the trust relationship. It is not necessary to locate all of the affected user ids and disable each account.

SSO via Secure Sockets Layer

Not all enterprise computer users enter a network by means of network-to-network connections. Modern enterprise computing must also support users who access their corporate network through internets. These can include mobile users who access the corporate network via the Internet and corporate partners who need access to the corporate intranet. Microsoft provides SSO for these customers via the Secure Sockets Layer (SSL) security protocol.

The SSL protocol uses digital certificates as a basis for authentication. A digital certificate is a tamper-proof packet of data issued by a Certificate Authority (CA) that provides a public key and a name and vouches for the fact that the person or server named is the owner of the public key. In the mode used for SSO, the Web client and server exchange certificates, then use the public keys embedded in them to exchange information such as session encryption keys. This serves to authenticate both users, because if either is not the actual entity named in the certificate they presented, they will be unable to decrypt what the other party sends. For a full description of the SSL protocol, consult the IETF draft specification located at: https://www.ietf.org/rfc/rfc2246.txt.

Figure 8: Basic Transactions in SSL Authentication

Full Integration within Windows 2000

All of the components needed to provide SSO via SSL are natively included within Windows 2000, and all are fully integrated into the Windows 2000 security architecture. Management of digital certificates is provided by the Windows 2000 Public Key Infrastructure (PKI), which has two components: Certificate Services, which allows administrators to issue and revoke certificates; and Active Directory, which provides CA location and policy information and allows revocation information to be published. Web hosting services in Windows 2000 are provided by Microsoft Internet Information Service (IIS), its built-in full-featured Web server that utilizes the Windows 2000 security architecture to provide SSL and other security services.

Figure 9: Windows 2000 Components Providing SSL-Based SSO

Administrative Ease and Flexibility

The integration of SSL and digital certificates into the Windows 2000 platform is mirrored by the integration of SSL- and certificate-related management tools within the Windows 2000 administrative tool kit. All of the administrative tasks needed to provide SSO via SSL are performed via MMC snap-ins like the Active Directory Manager, Certificate Services Manager, and IIS Manager.

Figure 10: Certificate Services Manager Interface

Administrators have considerable flexibility to configure the network's use of security information to suit their corporate needs. For example, they can specify by means of IIS whether certificates can be used only to authenticate to the Web server, or whether they can be the basis of a full network logon. They can associate individual certificates with individual user accounts, or they can state that all certificates from a particular CA map to a single guest account. Finally, they can enable the use of certificates issued by an external CA within the enterprise or establish the enterprise as its own CA.

Seamless Interoperability

Microsoft's SSL-based SSO is fully standards based, and interoperates easily with other standards-compliant products. It supports SSL version 3, the most widely used version of the SSL protocol, which has been submitted to the Internet Engineering Task Force (IETF) under the name Transport Level Security (TLS) protocol. Microsoft Internet Explorer, Netscape Communicator, and most other Web browsers support this standard and are supporting TLS' adoption by the IETF. The Windows 2000 PKI supports digital certificates using the ISO's X.509 version 3 standard. This is a nearly universal standard for digital certificates, and allows Windows 2000 to use digital certificates issued by VeriSign, Thawte, Belsign, and most other certificate authorities.

In addition, the Windows 2000 operating system provides programming interfaces that make it easy for third-party developers to build products that will interoperate with it. Developers can use SSPI to leverage the Windows 2000 security architecture and participate in SSL authentication. Using the CryptoAPI programming interface, they can access the Windows 2000 PKI and request certificate-handling functions.

Improved Security

Access control can be easily and effectively managed because, although digital certificates are used for the initial authentication of the user, the control point for access to network resources remains the user account. After authenticating the user, Windows 2000 maps the certificate to the appropriate user account and uses the user's normal security credentials to access network resources. This eliminates the need to keep multiple copies of the user's privileges synchronized.

Session security is significantly improved because encryption is provided as part of the SSL protocol implementation. This allows an enterprise to determine the preferred level of encryption for Web-based network access, and to establish it when the session begins. To comply with US export law, Windows 2000 provides a North American version and an International version of its SSL implementation. The North American version provides 40-bit and128-bit versions of the RC2 and RC4 crypto-algorithms; 512-, 768-, and 1024-bit version of RSA; and 56-bit DES encryption. The International version provides 40-bit RC2 and RC4, and 512-bit RSA encryption.

Finally, digital certificates whose private keys have been compromised, or whose owners no longer require access to network resources, can be marked as revoked via Certificate Services. The network consults the Certificate Revocation List and refuses access to certificates that are authentic but not valid. This enables administrators to ensure that terminated employees, hackers, and thieves cannot gain access to the network.

SSO via SNA Server

The previously discussed methods of providing SSO did so by means of open-industry standards like the Kerberos and SSL protocols. However, a member of the Microsoft BackOffice family of products, SNA Server, works in conjunction with proprietary security protocols implemented by packages such as RACF, ACF2, and Top Secret to provide SSO between Windows NT-based networks and MVS/ESA and AS/400 mainframe systems.

SNA Server is packaged with Proginet SecurePass, and the two products work in tandem. SecurePass provides password synchronization services that ensure that a user's security credentials are always identical on both systems. This allows SNA Server to perform password stuffing. When the mainframe's security provider requires authentication, SNA Server supplies the user's Windows NT password (which is identical to his mainframe password because of the password synchronization) via an automated 3270 or 5250 logon.

Improved Security

In addition to providing the usual benefits of SSO, SNA Server delivers improved security by providing a capability to encrypt the user's Windows NT-mainframe sessions. This helps prevent an attacker from using a network sniffer to compromise the user's password, as well as protecting the session data.

In addition, SecurePass can significantly improve security by making it more consistent. Its password synchronization features ensure that when an administrator revokes a user account on one system, the password is disabled on the other as well. It performs password harmonization as well. When the user's password is changed on one system, it is subjected to the password rules on both systems before it is accepted. This effectively makes the corporate password policy be the stronger of the Windows NT/IBM policies, and prevents weak password policies on one system from threatening the security of the other.

Summary

Every computing enterprise can benefit from an SSO capability. Users are more productive when barriers are removed between them and the resources they are authorized to use. Networks can be managed with fewer administrators because of the consolidation of management information. Network security is improved by the use of secure authentication protocols and the elimination of the most common threat to network security: users writing down their passwords.

Windows 2000, through its use of industry-standard versions of the Kerberos and SSL protocols, helps ensure interoperability with other vendors' implementations, allowing SSO to be provided within large mixed environments. In addition, SNA Server provides a means of extending SSO to a mixed Windows 2000 and mainframe environment via proprietary mainframe security protocols. This combination makes Windows 2000 the best choice to serve as an interchange point within large mixed environments.

However, the best SSO capability is provided within homogeneous Windows 2000-based networks, and customers who deploy homogeneous Windows 2000 networks will enjoy the most dramatic benefits. All applications that carry the BackOffice logo provide support for Windows 2000 SSO natively, ensuring widespread availability of SSO-enabled applications. In addition, the integration of the Kerberos and SSL protocols within the Windows 2000 security and management models is mirrored by the integration of SSO-related tools into those the administrator already uses. Network efficiency is improved, and security is enhanced by the ability to perform mutual authentication and to delegate authentication within multitiered applications. All of these factors add up to significantly improved Total Cost of Ownership.

Additional Information

For the latest information on Windows NT Server, check out Microsoft TechNet or visit our website at https://www.microsoft.com/ntserver or the Windows NT Server Forum on the MSN network of Internet services (GO WORD: MSNTS).

1	The lifetime of a Kerberos ticket is configurable and can be set in accordance with a corporate security policy.