다음을 통해 공유

Digest Authentication

  • 아티클

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Digest authentication offers the same functionality as Basic authentication; however, Digest authentication provides a security improvement because a user's credentials are not sent across the network in plaintext. Digest authentication sends credentials across the network as a Message Digest 5 (MD5) hash, which is also known as the MD5 message digest, in which the credentials cannot be deciphered from the hash.

If your server is running an earlier version of IIS with Digest authentication enabled and you upgrade to IIS 6.0, Digest authentication remains the default authentication method. In all other instances, you must enable Digest authentication.

Client Authentication Process for Digest Authentication

Figure 5.1 shows how a client is authenticated using Digest authentication. The steps that follow the figure describe the process in more detail.

Art Image

  1. The client requests a file from the server running IIS.

  2. The server running IIS denies the request and sends the client the following information:

    1. Digest authentication is being used.

    2. The realm name.

  3. Internet Explorer prompts the user for credentials (user name and password). Internet Explorer then combines these credentials with the name of the realm to create an MD5 hash and resubmits the request for the file from the server running IIS, this time sending the MD5 hash.

  4. The server running IIS receives the hash and sends the client's hash to the domain controller for verification.

  5. The domain controller informs the server running IIS of the authentication results.

  6. If the client is authenticated, IIS sends the requested document or data to the client.

Important

Digest authentication completes only if the domain controller has a reversibly encrypted (clear text) copy of the requesting user's password stored in Active Directory. To allow passwords to be stored in clear text, you need to activate the Store password using reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set a Group Policy to enable this capability. After making this setting you need to set a new password to activate this feature because the old password cannot be determined. For more information about setting user properties in Active Directory, see Help and Support Center for Windows Server 2003.

Requirements for Digest Authentication

You do not need to install additional client software to use Digest authentication, but Digest authentication relies on the HTTP 1.1 protocol, as defined in RFC 2617 HTTP Authentication: Basic and Digest Access Authentication, and not all browsers support that protocol. If a non–HTTP 1.1–compliant browser requests a file from a server that uses Digest authentication, the server requests that the client provide Digest authentication credentials. The non–HTTP 1.1–compliant browser rejects the request because the client cannot support Digest authentication. For more information about HTTP authentication, see RFC 2617, HTTP Authentication: Basic and Digest Access Authentication on the Internet Engineering Task Force Web site.

Before you enable Digest authentication on your server, ensure that:

  • All of the clients that need access to a resource that is secured with Digest authentication are using Internet Explorer 5.x or Internet Explorer 6.

  • The user and the server running IIS are members of, or are trusted by, the same domain.

  • Users have a valid Windows user account that is stored in Active Directory on the domain controller, with reversible encryption enabled.

  • The domain has a domain controller running the Microsoft® Windows®  2000 Server operating system or Windows Server 2003.

    Important

    If the authenticating domain controller is on a computer running Windows2000 Server, IIS6.0 requires subauthentication for Digest authentication to work. For more information about subauthentication, see Using Sub-Authentication with Digest Authentication later in this topic.

  • The server running IIS 6.0 is running Windows 2000 Server or Windows Server 2003.

  • If the server operates in worker process isolation mode, the application pool that contains an application that uses Digest authentication must run with LocalSystem as the worker process identity. This requirement applies because a user password is not stored outside the hash that the client sends to IIS, and a worker process that is associated with the application cannot impersonate the user by using the user name and password.

  • The Iissuba.dll file is registered on the server running IIS.

Note

Only domain administrators can verify that the domain controller requirements are met. Check with your domain administrator if you are unsure about whether your domain controller meets the preceding requirements.

Enabling Digest authentication on a server running IIS requires the following two tasks:

  • Enabling Digest authentication for Windows domain servers. For more information about enabling Digest authentication for Windows domain servers, see Help and Support Center for Windows Server 2003.

  • Configuring the realm name at any level of the metabase by using IIS Manager or by scripting.

Note

If Basic authentication is enabled for the site, virtual directory, or folder you are configuring, the Default domain box will also be available. However, only Realm is meaningful to Digest authentication.

Configuring the Realm Name

Table 5.4 lists and describes the levels of the metabase where the realm name can be configured. If a child key is not specifically configured, it inherits its configuration from the next configured level up.

Table 5.5 Metabase Levels Where the Realm Name Can Be Configured

Metabase Level Description

W3SVC

The W3SVC level, also known as the IISWebService level, is the highest level in the metabase where Digest authentication can be configured. Configurations set at this level are inherited by lower levels that do not have specific configuration settings.

W3SVC/n

The W3SVC/n level, also known as the IISWebService level, is a specific Web site, where n is the number of the site. Sites are numbered starting at 1. The default Web site is 1.

W3SVC/n/root

The W3SVC/n/Root level, known as the IISWebVirtualDir level, is the starting point for a Web Site, where n is the number of the site.

W3SVC/n/root/vdir

The W3SVC/n/ROOT/WebVirtualDir level, known as the IISWebVirtualDir level, is a virtual directory within a Web Site, where n is the number of the site.

W3SVC/n/root/vdir/webdir

The W3SVC/n/Root/WebVirtualDir/WebDir level, also known as the IISWebDirectory level, is a physical directory within a virtual directory within a Web site, where n is the number of the site.

W3SVC/n/root/vdir/file

The W3SVC/n/root/vdir/file level is an individual file within the W3SVC/n/ROOT/WebVirtualDir level, where n is the number of the site.

W3SVC/n/root/webdir/file

The W3SVC/n/root/vdir/file level is an individual file within the W3SVC/n/Root/WebVirtualDir/WebDir level, where n is the number of the site.

You can configure one or multiple realm names on a server running IIS. For example, you might want to configure multiple realm names to allow members of Domain1 to access the Sales directory, and members of Domain2 to access the Engineering directory. This is particularly useful if no trust relationship exists between Domain1 and Domain2. If you configure multiple realm names, they must be configured at different levels of the metabase. For more information about domains, see Help and Support Center for Windows Server 2003.

If a child key in the metabase is not configured with a realm name, that child key inherits the realm name from the next parent key that has the realm name configured. If the realm name is not configured, IIS sends its own computer name as the realm name. If IIS sends its own name as the realm name and IIS is not running on a Windows Server 2003 domain controller with Active Directory, Digest authentication will fail.

For step-by-step instructions for configuring Digest authentication, see Digest Authentication in IIS 6.0.

Using Sub-Authentication with Digest Authentication

To use Digest authentication in IIS 6.0 when the domain controller is running Windows 2000 Server, you must enable sub-authentication. The sub-authentication file, Iissuba.dll, is automatically copied to the %Windir%\System32 folder when you install Windows 2000 Server and Windows Server 2003. However, by default, sub-authentication is not enabled in IIS 6.0. To enable sub-authentication, you must perform the following tasks:

  • Install the sub-authentication component, iisuba.dll.

  • Set the UseDigestSSP metabase property to false.

    Note

    The W3SVC service must be restarted before changes to this property take effect.

  • Set the identity of the application pool to LocalSystem.

For more information about how to configure sub-authentication, see Configuring Subauthentication.

Logging on with a user principal name (UPN) in the form username@domain.com will still fail at this point, even though your IIS 6.0 server is a member of a Windows 2000 domain and is correctly configured for Digest authentication as well as subauthentication.. This failure occurs because Digest authentication accepts only domain logons in one of the following formats:

  • If a user logs on to a server in the same domain where the user's account resides, the username alone is sufficient for authentication.

  • For logons with a user account from another domain, use the domain\username format.

Understanding the MD5 Hash

An MD5 hash is used for sending encrypted user credentials across a network within an HTTP header. An MD5 hash, also known as the MD5 message-digest, is created by an HTTP 1.1–compliant browser such as Internet Explorer 5 and above, using the MD5 message-digest algorithm as defined in RFC 1321, The MD5 Message-Digest Algorithm.

Note

The MD5 hash is a security improvement over base64 encoded clear text passwords. An unauthorized person can easily intercept base64 encoded passwords by using a network sniffer, and decoding the passwords is a trivial matter. A user name and password that is encrypted using the MD5 message-digest algorithm cannot feasibly be decrypted from the hash.

An MD5 hash contains a user name, password, and the name of the realm. The realm is the domain that will authenticate or reject the users credential. The users credential is the password that is encrypted within the MD5 hash.

MD5 Hash Properties

An MD5 hash consists of a small amount of binary data, typically no more than 160 bits, and is sent by across the network within an HTTP header. All hash values share the following properties:

  • Hash length. The length of the hash value is determined by the type of algorithm used, and its length does not vary with the size of the message. The most common hash value lengths are either 128 or 160 bits.

  • Non-discoverability. Every pair of nonidentical messages will translate into a completely different hash value, even if the two messages differ only by a single bit. Using today's technology, it is not feasible to discover a pair of messages that translate to the same hash value.

  • Repeatability. Each time a particular message is hashed using the same algorithm, the exact same hash value will be produced.

  • Irreversibility. All hashing algorithms are one-way. Given a hash value, it is not feasible to discover the password. In fact, none of the properties of the original message can be determined given the hash value alone.

For more information about the MD5 message-digest algorithm, see RFC 1321, The MD5 Message-Digest Algorithm, on the Internet Engineering Task Force Web site.