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.
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.
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.
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 Enable, Disable, 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.
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.
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:
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.
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.
Windows Authentication is best suited for intranet environments.
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.
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 Enable, Disable, 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.
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.
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:
Multiple application pools can use Kerberos authentication.
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.
- IIS 7.0 : Implementing Access Control – Authentication (part 1)
- IIS 7.0 : Implementing Access Control – Authentication (part 3) – IIS Client Certificate Mapping Authentication
- IIS 7.0 : Implementing Access Control – Authentication (part 4)