Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

9.4 SSO technologies in Windows Server 2003 and XP

Table 9.10 provides an overview of the specific SSO technologies that are currently provided or that will be provided in the near future by Microsoft. Some of them (as mentioned in Table 9.10) are covered in more detail in this book.

9.4.1 The Credential Manager

The requirement that users must reenter the same credentials whenever they access resources on the same Internet or intranet server .can be frustrating for users, especially when they have more than one set of credentials. Administrators often must cope with the same frustration when they have to switch to alternative credentials to perform administrative tasks.

Prior to Windows XP and Windows Server 2003, Microsoft provided similar application-specific solutions, such as the Microsoft Internet Explorer’s (IE’s) credential-caching mechanism. In Windows Server 2003 and XP, Microsoft integrates a universal solution: the Credential Manager. The Credential Manager is a client-based SSO solution that uses an intelligent credential-caching mechanism.

Credential Manager consists of three components: the credential store, the key ring, and the credential collection component. The Credential Manager keeps user credentials in a client-side credential store. Windows 2003 and XP use the Data Protection API (DPAPI) to secure access to the credential store content. Because the credential store is part of a user’s profile, the store supports roaming. The store is unlocked using the user’s “primary credentials” (they are also referred to as the default credentials). When users log on locally to a machine or domain, they use their primary credentials. The credential store contains credential-target maps.

• A set of credentials can take one of three forms: a user ID and password, a user ID and a certificate/private key, or a set of MS Passport credentials. Certificate/private key–based credentials can be stored on hard disk or on a smart card.

• A target is the resource the user accesses. To specify a target, you can use a DNS name or NetBIOS name. A target name can contain wild- cards. For example, entering *.hp.com as the target name makes the associated credentials available to all targets whose DNS name ends in hp.com. A target name is independent of the communication protocol that is used to access it—in other words, credential manager can deal with HTTP-, HTTPs-, FTP- and SMB-based resource access.

Similar to a ring that holds the keys your house, office, or car, the Credential Manager key ring holds sets of credentials. The key ring component lets you manage the credential store’s credential-target mappings and their properties. You view and modify the mappings and properties through the Stored User Names and Passwords dialog box, which Figure 9.9 shows. How you access the Stored User Names and Passwords dialog box depends on the OS and the OS’s User Interface (UI):

Figure 9.9: Credential Manager key ring UI.

• Windows Server 2003—Open the Control Panel Stored User Names and Passwords applet.

• XP’s classic UI—Open the Control Panel User Accounts applet. Click the Advanced tab, then select the Manage Passwords option.

• XP’s user-friendly UI—Open the Control Panel User Accounts applet and open the properties of the account with which you’re currently logged on. In the Related Tasks list, select Manage my network passwords.

You can’t modify all the credentials from the key ring UI. For example, you can’t modify Passport credentials. You must modify Passport credentials from the Passport Web site.

When Credential Manager detects that it can’t use the primary credentials (or the credentials with which the user is currently logged on) to access a target, its credential collection component displays the Connect to dialog box. This dialog box prompts the user for alternative credentials. When the user selects the Remember my password check box, Credential Manager adds the credentials to the credential store. Then, the next time the user accesses the same target, Credential Manager automatically uses these credentials without prompting the user.

When a user uses RAS to remotely log on to a Windows domain, Credential Manager automatically adds a wildcard target for the user’s logon domain (e.g., *.hp.net) and corresponding credentials to the credential store. Credential Manager uses these credentials as the user’s primary credentials during the RAS logon session. This entry represents a permanent credential cache addition—it remains in the cache after the RAS session has ended.

To see how Credential Manager operates, let’s consider a user named Bob who is working from his workstation, which is called bobws. Bob wants to access a share resource that’s on a server called devserv. As Figure9.10 shows, the following events occur:

1. User Bob logs on at machine bobws as bobws\bob (which is a local account).

2. Bob uses a Credential Manager aware application (e.g., Windows Explorer) or API to access a file share on a server named devserv. Bob accesses the share using the following Universal Naming Convention (UNC) name: \\devserv\share.

3. The application calls on the Local Security Authority (LSA) and an authentication package (Kerberos or NTLM; authentication packages were explained in Chapter 4) to authenticate to \\devserv.

4. The authentication package queries Credential Manager for a set of credentials to use when accessing \\devserv. Credential Manager does not find a specific set of credentials and returns Bob’s primary credentials bobws\bob (these are the credentials with which Bob logged on).

5. The authentication package tries to authenticate to \\devserv\ share using the primary credentials (bobws\bob) but fails.

6. The failure is communicated to the application, which calls on the credui component. Credui brings up the Credential Collection dialog box.

7. Bob enters appropriate credentials in the Credential Collection dialog box and selects the Remember my password check box to save the credentials.

8. The credentials are passed to the Credential Manager, which stores them in the credential store.

9. The application and authentication package use the new credentials to authenticate to \\devserv\share. This time the authentication succeeds.

As Figure 9.10 shows, Credential Manager provides a great deal of automation. However, it doesn’t automate all credential-relatedmanagement tasks. For example, suppose that the Credential Manager on your PC stores the credentials necessary to access a remote share on a file server. If the administrator for that file server changes the password to access the share, the password won’t automatically be changed in your PC’s Credential Manager, which might lead to an account lockout.

Figure 9.10: Credential Manager operation.

Administrators who don’t want client-side credential storage can disable Credential Manager with the Network Access: Do not allow storage of credentials or .NET Passports for network authentication Group Policy Object (GPO) setting. You can find this setting in the Windows Settings\Security Settings\Local Policies\Security Options directory. When configuring this setting, the change will not take effect until you restart Windows. This setting can be used in both domain and standalone Windows Server 2003 and Windows XP setups. In a domain environment an administrator can use a GPO to enforce the setting. In a local setup you would use the Local Security Policy settings to configure it. When credential manager is disabled, the Stored User Names and Passwords dialog box will show up empty and with disabled push-buttons; the Credential Collection Component dialog box will lack the “Remember my password” checkbox (as illustrated in Figure 9.11).

Figure 9.11: Dialog boxes after disablingCredential Manager.

Windows 2003 includes the Cmdkey tool, which lets you manage the credential store from the command line. You can use Cmdkey to add, delete, and list credentials from the command line (as illustrated in Figure 9.12 for a list operation).

Figure 9.12: Cmdkey operation.

9.4.2 Internet authentication service

The Internet Authentication Service (IAS) is Microsoft’s implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy. RADIUS is an IETF standard defined in RFCs 2865 and 2866. The IAS software comes with all Windows Server 2003 versions with the exception of the Web server edition. The RADIUS proxy function is new to Windows Server 2003. It allows the forwarding of RADIUS requests to other IAS or RADIUS servers.

In a Windows environment, IAS is often used in conjunction withMicrosoft’s Routing and Remote Access Server (RRAS) to provide access control functions to dial-up users.

The meaning of the word RADIUS is confusing because it does not reveal the full capabilities of a RADIUS server:

• A RADIUS server not only deals with the authentication, but it also provides authorization and accounting services. As such, RADIUS is a good example of a triple A service.

A RADIUS server not only serves dial-in (remote access) users, but it can also handle the access control requests of wireless users and users connecting over a virtual private network (VPN) connection. This is illustrated in Figure 9.13.

Figure 9.13: IAS scenarios.

The main reason why IAS is discussed in this chapter is because it can provide an integrated SSO solution for Windows domain and network access—independently of whether the user connects over a dial-up, wireless, or VPN connection. IAS can provide this functionality because it can be integrated with Active Directory. This integration basically means that IAS uses the AD credential database to authenticate users.

IAS SSO also works across multiple Windows domains that are in the same or in different forests:

• To make SSO work across different domains, add the IAS and RRAS (used for remote access) servers to the built-in RAS and IAS Servers group in every domain of the forest.

• To make SSO work across different forests, use an IAS RADIUS proxy in every forest that is pointing to a central RADIUS server.

IAS supports different authentication methods, which are listed in Table9.11.

This chapter illustrated the complexity behind setting up an SSO architecture. This is the main reason why for many companies SSO will remain a holy grail for years to come.

As for any security solution, it is also recommended for an SSO solution to keep it simple and rely on open standards. For many organizations it may be much more realistic and feasible to plan for a reduced sign-on solution instead of a universal single sign-on solution. Also, open standards (like the Kerberos and PKI SSO mechanisms) provide better security quality and more flexible interoperability options. If you choose a vendor-specific SSO solution (like the password synchronization and client-side and server-side credential caching mechanisms), you make your IT infrastructure very dependent on a single software vendor.