Impersonation in IIS 7.0

Question

I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.

In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.

Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.

These are the settings that I'm using on both IIS 6.0 and 7.0:

<authentication mode="Windows">
<identity impersonate="true">

What changed from 6.0 to 7.0?

Answer 1

There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).

Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:

Internal Server Error. This is HTTP Error 500.19: The requested page cannot be accessed because the related configuration data for the page is invalid.

Here is the workaround that is proposed:

Workaround:

1) If your application does not rely on impersonating the requesting user in the BeginRequest and AuthenticateRequest stages (the only stages where impersonation is not possible in Integrated mode), ignore this error by adding the following to your application’s web.config:

<validation validateIntegratedModeConfiguration="false"

/>

2) If your application does rely on impersonation in BeginRequest and AuthenticateRequest, or you are not sure, move to classic mode.

I hoped that was useful to understand how IIS 7.0 now works.

Answer 2

Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.

Answer 3

Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.

I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!

@Esteban - Clarified my not very useful in helping you answer.

Answer 4

Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.

I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.

If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.