Note For detailed information about Windows Integrated authentication, visit the following Microsoft Web site:
If the IIS server and the HTTP client that makes the Web request both support the Kerberos protocol, and IIS is configured to use Kerberos, log entries that resemble the following appear in the IIS log for the client request and server response:If either the IIS server or the HTTP client does not support the Kerberos protocol, or if the IIS server is configured to use only NTLM, the following types of log entries appear in the IIS log for the client request and server response:
Windows Integrated authenticationIIS can be configured to support the Negotiate protocol, the NTLM protocol, or both. In IIS 6.0 and in earlier versions, this is done by configuring the NTAuthenticationProviders metabase key. In IIS 7.0, this is done by setting the appropriate <Provider> element under the <windowsAuthentication> element in the ApplicationHost.config file or in the web.config file.
For more informationabout how to configure Windows Integrated authentication in IIS 6.0 and in earlier versions, click the following article number to view the article in the Microsoft Knowledge Base:
Kerberos authenticationThe following are two scenario-based examples. In the first scenario, IIS is configured to support both the Negotiate protocol and the NTLM protocol. In the second scenario, only the Negotiate protocol is supported.
Scenario 1 – Negotiate protocol and NTLM protocolIn this example, IIS is configured to support both the Negotiate protocol and the NTLM protocol. In IIS 6.0 and in earlier versions, this is done by setting the NTAuthenticationProviders metabase key to "Negotiate,NTLM". In IIS 7.0 and in later versions, both the Negotiate protocol and the NTLM protocol must be listed as providers in the <windowsAuthentication> section.
Note In the following examples, the request header and the response header are captured by using the Microsoft Network Monitor 3.2 tool. To download the latest version of the Network Monitor Tool, visit the following Web site:Note The win32 status of "2148074254" (also defined as -2146893042 / 0x8009030E / SEC_E_NO_CREDENTIALS) means "No credentials are available in the security package." In other words, the client has not sent any credentials.
After the client receives the 401.2 response from the IIS server, the client understands that IIS is configured to use Windows Integrated authentication instead of Anonymous authentication. Therefore, the client must provide appropriate authentication information in its request.
The client then makes a request that resembles the following:Note In this article, the Kerberos ticket in the Authorization:Negotiate header has been truncated.
The IIS server receives the request. The IIS server sees that the client has included authentication information by adding the Authorization: Negotiate header and value. If the client has sent valid credential information, authentication is successful. IIS then sends the following response:Note The detailed steps of how Kerberos authentication takes place is not included here. For more information about how Kerberos authentication works, visit the following Microsoft Web site:
Scenario 2 - Negotiate protocolIn the scenario in which IIS is configured to support only the Negotiate protocol instead of both the Negotiate protocol and the NTLM protocol, the request and response flow is the same. The logging in the IIS log is also the same. The difference is in the initial response that IIS makes to the anonymous request from the browser. In this case, IIS sends only the Negotiate header:
NLTM authenticationThe following is a scenario-based example in which IIS is configured to support only the NTLM protocol. In IIS 6.0 and in earlier versions, this is done by having the NTAuthenticationProviders metabase key set to "NTLM". In IIS 7.0 and in later versions, only the NTLM protocol must be listed as a provider in the <windowsAuthentication> section.
Again, Internet Explorer does not include any authentication information in the first request on a new connection:
If the IIS server is not configured to support Anonymous authentication, the server returns a 401.2 status that tells the client that the client is unauthorized. Together with the error status, the server also sends a list of authentication protocols that the server supports. The response headers that IIS returns in this NTLM-only scenario resemble the following:IIS then writes an entry that resembles the following to the IIS log: When the client receives the server's notification that the server supports the NTLM protocol, the client re-sends the request. The client includes authentication information in an Authorization header: As part of the NTLM handshake, the server acknowledges that the client has sent authentication information. However, the server needs the client to send more information. Therefore, the server returns another 401 response that resembles the following:IIS then writes an entry in the IIS log that resembles the following: The 401.1 status that IIS sends tells the client that the client must provide the remainder of the valid authentication information. The client receives this challenge. The client then sends one more request that resembles the following:When the IIS server receives this request, the IIS server communicates with a domain controller to complete the authentication request. When the client's authentication request is confirmed, IIS sends a response that resembles the following:Note The detailed steps of how NTLM authentication takes place is not included here. For more information about how NTLM authentication works, visit the following Microsoft Web site:
For more information about Microsoft Kerberos, visit the following Microsoft Web site:
For more information about the NTAuthenticationProviders metabase property in IIS 6.0, visit the following Microsoft Web site: