IIS 7.0 : Implementing Access Control – Authentication (part 2) – Digest Authentication & Windows Authentication

Digest Authentication

The Digest Authentication feature implements the Digest Authentication protocol, a standard HTTP authentication scheme defined in RFC 2617 and supported by some HTTP client software. Unlike basic authentication, the client sends an MD5 hash of the user name and the password to the server so that the real credentials are not sent over the network. The Digest Authentication scheme in IIS 7.0 was known as the Advanced Digest Authentication in IIS 6.0 (IIS 7.0 no longer supports the IIS 6.0 Digest Authentication). If successful, Digest Authentication authenticates the request with a Windows token corresponding to the user’s Active Directory account.

Note

Digest authentication is not part of the default IIS install. You can manually install it from the Security feature category through Windows Features On And Off on Windows Vista. You can also install it through the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008.

Like basic authentication, digest authentication is a challenge-based authentication scheme. When a client makes the initial request to a resource that requires authentication, and digest authentication is enabled, the request will be rejected with a 401 unauthorized status that includes a “WWW-Authenticate: digest” response header containing additional information required by the Digest Authentication scheme. If the client supports digest authentication, it will usually prompt the user for the credentials and then reissue the request with the hash of the credentials and the nonce information in the challenge. The Digest Authentication module will see that the hash is present on the subsequent request and attempt to authenticate the hash by comparing it with the hash stored in Active Directory. The client will typically send the hash information again on every request to the same URL or any URL below the URL used in the initial authenticated request.

The Web server and the clients accessing it must meet the following requirements to use IIS 7.0 Digest Authentication:

  • Both the Web server and the clients using your application must be members of the same domain, or the client must be a member of a domain trusted by the Web server.

  • The clients must use Microsoft Internet Explorer 5 or later.

  • The user must have a valid Windows user account stored in Active Directory on the domain controller.

  • The domain controller must be using Windows Server 2003 or Windows Server 2008.

Unlike the IIS 6.0 Digest Authentication, the IIS 7.0 Digest Authentication does not require the application pool identity to be LocalSystem. In fact, you should not ever use LocalSystem or any other identity with Administrative privileges on the server as an application pool identity.

Caution

Just enabling digest authentication does not mean that authentication is required for your application. You must either disable anonymous authentication and/or configure URL authorization rules or NTFS permissions that deny access to the anonymous user.

Unlike basic authentication, the authenticated token is not suitable for accessing remote resources, and it requires Constrained Delegation or Protocol Transition to be configured to do so.

You can enable or disable digest authentication by using IIS Manager. Select the desired node in the tree view and double-click Authentication. Then, select Digest Authentication from the list and use the EnableDisable, and Edit commands in the Actions pane to configure it.

You can also set digest authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/digestAuthentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath]
/section:system.webServer/security/digestAuthentication [/enabled:bool]
[/realm:string]

The parameters of this command are shown in the Table 1.

Table 1. Parameters for Setting Digest Authentication
ParameterDescription
ConfigurationPathThe configuration path at which to set the specified configuration. If specifying this, you may also need to specify the /commit:apphost parameter to avoid locking errors when applying configuration to Web site or URL levels.
enabledWhether to enable or disable digest authentication.
realmThe digest authentication realm that will be used as specified in the RFC 2617.

Windows Authentication

The Windows Authentication scheme enables Windows clients to authenticate with two Windows authentication protocols, NTLM (NT LAN Manager) and Kerberos. Both of these schemes involve a cryptographic exchange between the client and the server to authenticate the client.

Note

Unlike Windows Server 2003, Windows Authentication is not part of the default IIS install and is not enabled by default. You can manually install it from the Security feature category through Turn Windows Features On And Off on Windows Vista. You can also install it via the Security role service category of the Web Server (IIS) role in Server Manager on Windows Server 2008.

Windows Authentication, similar to other IIS authentication methods, is challenge-based. When a request is rejected with a 401 unauthorized response status code, Windows Authentication will issue a WWW-Authenticate challenge header including one or both of the following authentication scheme names:

  • NTLM Indicates to the client that it can use the NTLM authentication protocol to authenticate. This is included for older clients that do not support the negotiate wrapper.

  • Negotiate Indicates to the client that it can use Kerberos or NTLM protocols to authenticate. Negotiate is used to allow either Kerberos or NTLM authentication, depending on what is available on the client.

Note

Both Kerberos and NTLM authentication methods involve the client making several (typically two to three) requests to the server as part of the authentication handshake. This means that your modules may see multiple requests as part of the authentication process. By default, authentication occurs once per connection, so it does not occur again for subsequent requests using the same connection.

The client then makes the decision to use either Kerberos (if available) or NTLM and initiates a sequence of requests to authenticate using the selected protocol. The choice of protocol is based on whether or not the client is configured to be able to use Kerberos to authenticate with the server, which requires a direct connection to the Key Distribution Center (KDC) on the domain controller as well as direct access to Active Directory. NTLM can be used in a non-domain scenario against local Windows accounts on the server or when the connection to domain services required for Kerberos is unavailable.

Note

Windows Authentication is best suited for intranet environments.

Windows Authentication is a reasonable choice for Windows-based intranet environments, but for other environments, keep in mind the following limitations:

  • It does not work over HTTP proxies. This is because Kerberos and NTLM are connection-based, and proxies may not keep connections open or may share connections between requests from multiple clients.

  • The Kerberos protocol requires both the client and the server to be members of the same domain or two domains with a trust relationship and have a direct connection to Active Directory and the KDC services located on the domain controller.

  • The Kerberos protocol requires correct Service Principal Name (SPN) registration in Active Directory for all application pools performing Kerberos authentication.

Configuring Windows Authentication

You can enable or disable Windows Authentication by using IIS Manager. Select the desired node in the tree view and double-click Authentication. Then, select Windows Authentication in the list and use the EnableDisable, and Edit commands in the Actions pane to configure it.

You can also set digest authentication configuration directly; use Appcmd.exe from the command line, or use configuration APIs to configure the system.webServer/security/windowsAuthentication section. You do this with Appcmd by using the following syntax.

%systemroot%\system32\inetsrv\Appcmd set config [ConfigurationPath]
/section:system.webServer/security/windowsAuthentication [/enabled:bool]
[/authPersistSingleRequest:bool] [/authPersistNonNTLM:bool]
[/useKernelMode:bool] [/useAppPoolCredentials:bool]

The parameters of this command are shown in Table 3.

Table 3. Parameters for Configure Authentication
ParameterDescription
ConfigurationPathThe configuration path at which to set the specified configuration. If you specify this, you may also need to specify the /commit:apphost parameter to avoid locking errors when applying configuration to Web site or URL levels.
enabledWhether to enable or disable Windows Authentication.
authPersistSingleRequestWhether or not to require each new request to reauthenticate. If set to false, the client will perform the authentication handshake only once per connection, and the server will cache the authenticated identity for all subsequent requests. Otherwise, each request will require the authentication handshake. Default is false.
authPersistNonNTLMWhether to require each new request to reauthenticate when using Kerberos. If set to false, the client will perform the authentication handshake only once per connection, and the server will cache the authenticated identity for all subsequent requests. Otherwise, each request will require the authentication handshake. Default is false.
useKernelModeWhether to perform Windows Authentication in the kernel. The default is true.
useAppPoolCredentialsWhether to use the application pool identity instead of LocalSystem when performing kernel Windows Authentication. This is needed when you are using a domain account as the application pool identity to enable Kerberos authentication on a Web farm. The default is false.
 

In addition, you can also control whether the server uses NTLM or Negotiate protocols. To do this, you can edit the providers collection in the system.webServer/security/windowsAuthentication configuration section. By default, this collection contains both NTLM and Negotiate protocol providers. You can force the server to use only NTLM by removing the Negotiate protocol provider. However, you cannot force the server to use only Kerberos in this configuration, because the negotiate wrapper enables the client to use either NTLM or Kerberos. There is no way to tell the client that only Kerberos is supported.

You can, however, configure the NTLM authentication level by using the Local Security Policy console and modifying the Security Settings\Local Policies\Security Options\Network Security: LAN Manager Authentication Level option, as shown in Figure 1. The default setting is Send NTLMv2 Response Only, which enables the server to accept all levels. You can set this setting to Send NTLMv2 Response Only. Refuse LM & NTLM for maximum security while allowing clients that do not have the ability to use Kerberos to use the NTLMv2 scheme.

 

Figure 1. Configure NTLM Authentication Level.

 

In IIS 6.0, to use the Kerberos authentication protocol, you have to use the Setspn.exe command line tool to register Service Principal Names (SPNs) in Active Directory for the NetBIOS and the Fully Qualified Domain Name (FDQN) names for each application pool account. Additionally, you could have only one application pool account registered for each SPN, preventing multiple application pools with different identities from using Kerberos authentication.

In IIS 7.0, kernel-based Windows Authentication (enabled by default) offers improved functionality. Because HTTP.sys performs the authentication process in the kernel, it is done under the LocalSystem account regardless of the application pool identity. This results in the following improvements:

  • It should no longer be necessary to configure separate SPNs, because Kerberos will use the default NetBIOS SPN entry created automatically when the Web server computer is joined to the domain.

  • Application pool identity can be changed without the need to reregister the SPN with the new account. The application pool account no longer needs to be a domain account.

  • Multiple application pools can use Kerberos authentication.

These changes make it significantly easier to deploy and use the Kerberos protocol with IIS.

Note

You need to use the application pool identity and register SPNs for Kerberos authentication when you are using it on a Web farm.

However, if you are using IIS on a Web farm and require the Kerberos protocol, you will need to disable the use of the LocalSystem identity for Kerberos authentication by setting the useAppPoolCredentials attribute in the system.webServer/security/authentication/windowsAuthentication configuration section to true. In addition, you will need to use a domain account as an identity for the application pool. You will also be required to use Setspn.exe to register the Web site host name using this domain account under which the application pools are configured to run in Active Directory.