Single Sign-On

Log on and access resources across a network from multiple platforms

Single sign-on (SSO) is a term users frequently refer to, but it has different meanings depending on the user and the situation. SSO encompasses any technology that facilitates logging on and accessing resources across a network from multiple platforms. The SSO process isn't necessarily a one-step process and doesn't always involve a sign-on. For example, SSO solutions sometimes ask for further authentication information for access to a different system or network. SSO mechanisms can also authenticate a user who hasn't signed on to a system (which isn't particularly useful but possible). In this article, we explore the basics of SSO, provide pertinent definitions, and examine SSO solutions for Windows 2000 (Win2K) and Windows NT.

For organizations that have important business applications involving more than one platform, SSO solves several problems. For authentication on multiple systems, users must remember numerous passwords and tackle several interfaces. Users therefore often select simple passwords or write their passwords on a sticky note, potentially causing security breaches. In addition, administrators must navigate through several management interfaces to add users, remove users, or change passwords on multiple, disparate systems such as NT, UNIX, and Novell NetWare. This process is cumbersome and can reduce network security. SSO solves these problems.

SSO is most complex in mixed environments because no universal solutions apply to all OSs and environments. Therefore, an organization must identify the scope of SSO and limit the SSO solution to a few applications or platforms. Several SSO technologies are available for organizations to tailor solutions to specific problems. These SSO options include password synchronization, logon automation, and token-based authentication.

Password Synchronization
Synchronizing passwords across multiple OSs might be a sufficient solution for organizations that are primarily concerned about forgotten passwords. In an NT network that also has NetWare servers, you can use one password to log on to the NetWare server and the NT domain. However, this process isn't strictly an SSO solution because you must log on to both systems, even though you're applying one password.

Using password synchronization reduces the number of Help desk calls related to forgotten passwords and is a cost-effective solution to this problem. The user must remember only one password instead of multiple passwords. One problem with this approach, however, is that if someone decodes the password on one system, all the other systems are vulnerable. Therefore, if an organization chooses password synchronization, it needs to ensure the security of all its systems. (For a review of password synchronization products, see Randy F. Smith, "SAM/PS, P-Synch 3.5," October 1999.)

Logon Automation
Logon automation involves a centralized database that contains a user or a client computer with access to various resources. You modify the client interface to provide shortcuts or links to all the resources the user or computer can access. The logon process is automatic because the user doesn't need to log on to each resource.

With the combination of shortcuts and the centralized database, access to resources on disparate systems is transparent to the user. Each time a user clicks a link to a resource, stored scripts run from the database to give appropriate credentials to the target system for access without additional user logon.

The logon automation approach lets users who aren't part of an organization's SSO solution independently access specific servers. For example, a consultant can access a UNIX computer even though he or she isn't in the SSO authentication database. In a large enterprise network, however, letting nonauthenticated users access a system might reduce security.

Compared with password synchronization, logon automation provides a higher level of security because each target system has a unique password. The password can be different on different systems, and you can tailor the strength of the password to individual applications.

Kerberos and Token-based Authentication
Kerberos is a token-based authentication scheme for users and servers to authenticate one another through a trusted third party, called the Kerberos Key Distribution Center (KDC). The Kerberos KDC provides tickets (or tokens) to authenticate clients and temporary session keys that clients use as temporary encryption keys during logon sessions.

An individual's token is unique and doesn't work for other users. Tokens let clients and servers identify one another, even on a nonsecure network, and encryption keys prevent security compromises. Each application service on a network must be capable of responding to valid tokens by allowing user access.

Win2K uses Kerberos to minimize problems involved with multiple logons and passwords. Microsoft added access-control features to Kerberos to provide additional functionality for Win2K users. The Kerberos KDC in Win2K uses Active Directory (AD) as a user account database.

Unlike in NT 4.0, Win2K clients can use tokens on other platforms. If a client supports Kerberos 5, the client can use Win2K as a hub for SSO solutions. For example, a client using a system that runs on a different platform (e.g., Sun Microsystems' Solaris, Digital UNIX) can authenticate to a Win2K domain controller.

SSO in NT
Several vendors offer a variety of SSO solutions for NT. For a list of available SSO products, see "SSO Solution Resources."

SSO solutions for NT are based on the use of other application services, such as SNA Server. (For mainframes and legacy systems, you can use SNA Server, which is part of Microsoft BackOffice, as an SSO solution.) Because NT uses SIDs to identify users and tokens to represent users, SSO solutions aren't integral to NT operation. In contrast, Microsoft designed Win2K with SSO in mind.

SSO in Win2K
Win2K has built-in support for Kerberos. (For information about Kerberos, see Jan De Clercq, "Kerberos in Win2K," October 1999.) Because all application services running on Win2K use AD, Microsoft predicts that SSO solutions based on Win2K will result in simpler administration and finer control. Win2K uses the Microsoft Management Console (MMC), which manages SSO-related tasks as part of standard Win2K administration. Because Microsoft built SSO features into AD, changes to permissions and privileges are effective across an enterprise network.

Win2K: The SSO Solution Hub
SSO solutions encompass several mechanisms, such as password synchronization, logon automation, and token-based authentication. Win2K's integration of technologies and clients makes the OS an effective SSO hub. Table 1 lists SSO technologies for Win2K clients. For more information about how Win2K implements SSO solutions, see the Microsoft TechNet articles "Single Sign-On in Windows 2000 Networks" (http://technet.microsoft.com/cdonline/default-f.asp? target=http://technet.microsoft.com/cdonline/ content/complete/windows/win2000/win2ksrv/prodfact/nt2ksso.htm) and "Secure Networking Using Windows 2000 Distributed Security Services" (http://technet.microsoft.com/cdonline/default-f.asp? target=http://technet.microsoft.com/cdonline/content/complete/ windows/win2000/win2ksrv/technote/disesewp.htm).