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 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.
Table 1. Parameters for Setting Digest Authentication
| Parameter | Description |
|---|
| ConfigurationPath | The 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. |
| enabled | Whether to enable or disable digest authentication. |
| realm | The 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 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.
Table 3. Parameters for Configure Authentication
| Parameter | Description |
|---|
| ConfigurationPath | The 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. |
| enabled | Whether to enable or disable Windows Authentication. |
| authPersistSingleRequest | Whether
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. |
| authPersistNonNTLM | Whether
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. |
| useKernelMode | Whether to perform Windows Authentication in the kernel. The default is true. |
| useAppPoolCredentials | Whether
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.
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.
