Deciphering Basic, Digest, and Integrated Windows Authentication

What are the differences between Basic, Digest, and Integrated Windows authentication in Microsoft IIS? And, how can a user recognize whichauthentication option is being used from within Microsoft Internet Explorer(IE)?

Basic authentication is part of the HTTP 1.0 protocol specification, which means it works with any browser type. Basic authentication provides a simple mechanism for transmitting user credentials (i.e., a user ID and password) from a browser to a Web server. Credential information that you transfer using Basic authentication isn't secure—it's just base64 encoded. Base64 encodes messages by storing every three 8-bit characters in four 6-bit characters. Decoding base64-encoded messages is easy, and someone spying on these transmissions could easily decode the base64 encryption by simply using one of several online base64-decoder tools such as the tool available at http://www.robertgraham.com/tools/base64coder.html. As a result, you should use the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols to secure Basic authentication HTTP traffic.

When you use basic authentication to access a Web resource, you can configure the default domain and realm at the bottom of the Internet Services Manager (ISM) Authentication Methods dialog box. In the sample Basic authentication dialog box that Figure 1 shows, the user has provided a domain called “dc” (the domain name precedes the username). The realm is the level within the IIS metabase hierarchy that a user can access when using Basic authentication. By default, this realm is the IIS computer name, which provides access to all levels in the IIS metabase hierarchy. When you specify a custom realm for a Web resource, it automatically appears in the Basic authentication dialog box for that resource.

Digest authentication was originally part of the HTTP 1.0 protocol specification and later enhanced in the HTTP 1.1 protocol specification. Internet Engineering Task Force (IETF) Request for Comments (RFC) 2617 defines both versions. Similar to NT LAN Manager (NTLM) authentication, Digest authentication uses a challenge/response-based authentication method. One of the key advantages of Digest authentication is that it doesn’t transmit the user's credentials in the clear over the network, like Basic authentication does, and thus doesn't require the use of SSL or TLS.

Not all browser and Web server types and versions currently support HTTP 1.1 and Digest authentication—on the Microsoft side, only IE 5.0 and later and Internet Information Services (IIS) 5.0 and later provide support. A major disadvantage of Digest authentication is that it relies on Active Directory (AD) user accounts. As a result, the user's password is stored in clear text in AD. To set clear-text password storage in AD, you use a property of the user object called “Store Password using Reversible Encryption.” (This property is on the Account tab of the user object Properties dialog box.)

When you use Digest authentication, the user will see a typical authentication dialog box on the browser side, as Figure 2 shows. The dialog box explicitly refers to the name of the resource the user is trying to access and the use of Digestauthentication.

IIS's integrated Windows authentication consists of two authentication protocols: NTLM and Kerberos. Integrated Windows authentication calls on three different Security Support Providers (SSPs): the Kerberos, NTLM, and Negotiate SSPs. These protocols and SSPs are the ones typically available and used on Windows networks. However, instead of using the remote procedure call (RPC) protocol, IIS uses HTTP to transport Integrated Windows authentication messages in a Web environment.

As with Digest authentication, Integrated Windows authentication never transmits the password in the clear and, therefore, doesn't require the use of SSL or TLS. One consideration to keep in mind when using this authentication method is that because the Negotiate SSP and the NTLM authentication protocol both require a point-to-point connection between the browser and the Web server, neither one will work across HTTP proxies.

Unless the user can use his or her current logon credentials to authenticate to the Web server, using Integrated Windows authentication will generate a typical authentication dialog box on the browser side, as Figure 3 shows. The words "Connecting to" followed by the name of the Web resource that the user is attempting to connect to always appear in the upper left of the authentication dialog box.