Kerberos authentication in IIS 7

We have some web content that is setup in virtual directories using integrated windows authentication. The virtual directories are running under application pools that are using a custom identity (custom user account). The problem is that NTLM authentication works however Kerberos authentication does not. This is the same configuration that worked under IIS 6 but we need to migrate to IIS 7 and Kerberos authentication isn't working.

Here's some more information about my environment:

Virtual Directory Authentication Settings:

• Everything disabled except for Windows Authentication
• Enable kernel-mode authentication: enabled

App Pool Settings:

• Managed Pipeline Mode: Classic
• Identity: Custom local user

Web.config Settings:

• authentication mode = "Windows"
• system.serviceModel/bindings/basicHttpBinding/binding/security/mode = TransportCredentialOnly
• system.serviceModel/bindings/basicHttpBinding/binding/security/transport/clientCredentailType = Windows
• serviceHostingEnvironment/aspNetCompatibilityEnabled = true

Virtual Directory Permissions:

• Custom local groups: We add domain users to the local groups for access to the service

OS settings:

• IIS 7
• Windows Server 2008 x64 standard SP2

Here is the analysis I get from fiddler comparing IIS 6 to IIS 7. Kerberos authentication is working fine in IIS 6 with a app pool running with a custom identity.

Reference (IIS 6) (Works):

Fiddler:

(Using domain\user)

Request 1 (no auth)

No Proxy-Authorization Header is present.
No Authorization Header is present.

Response 1 (401) (challenge)

No Proxy-Authenticate Header is present.
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

Request 2 (Kerberos ticket)

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
<data>

Response 2 (401) (Kerberos reply)

WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
<data>

Request 3 (Kerberos ticket)

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
<data>

Response 3 (401) (Kerberos reply)

WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
<data>

Request 4 (Kerberos ticket)

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
<data>

Response 4 (200) (Kerbero开发者_开发技巧s Reply)

WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
<data>

And the transaction completes and the browser displays the page.

(IIS 7) (Doesn't Work):

Fiddler:

(Using domain\user)

Request 1 (no auth)

No Proxy-Authorization Header is present.
No Authorization Header is present.

Response 1 (401) ( Negotiate)

No Proxy-Authenticate Header is present.
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

Request 2 (Kerberos ticket)

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
<data>

Response 2 (401) (Negotiate)

No Proxy-Authenticate Header is present.
WWW-Authenticate Header is present: Negotiate
WWW-Authenticate Header is present: NTLM

Notice that IIS 7 isn't accepting my Kerberos ticket in Response 2. Any idea why not? Do I need to reconfigure some stuff in IIS 7 to get Kerberos authentication to work?

RESOLUTION

In order for me to get IIS 7 to negotiate authentication as IIS 6 does I had to set the useAppPoolCredentials of the windowsAuthentication element of my virtual directory in the applicationHost.config file to true. This is done doing either one of these commands:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true

To apply to individual applications:

First unlock :

%windir%\system32\inetsrv\appcmd.exe unlock config /section:windowsAuthentication

Then apply:

%windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/myApp/" /section:windowsAuthentication -useAppPoolCredentials:true

NOTE - This actually doesn't make Kerberos work. What it does it make IIS 7 behave like IIS 6. What this means is that if Kerberos negotiation between the server and client fails then the server automatically falls back to NTLM. This is actually the thing that made authentication work for me (NTLM).

Are you using the Negotiate:Kerberos provider for Windows Authentication? If there is a problem around Kerberos, you might be able to get more details on the problem by running Network Monitor (or something similar like WireShark) on the client, while trying to authenticate. Look at the messages in the Internet Explorer process and you may be able to see some Kerberos goings-on.