CODEWITHSUNDEEP
asp.netiisimpersonationpool
Todd Beaulieu
Todd Beaulieu

Reputation: 657

IIS still accessing resources via pool identity, not impersonated user

I'm at my whitt's end!

On Server 2003, I have an INTRANET app configured to use BASIC AUTHENTICATION and an app pool with a dedicated account.

In web.config I'm specifying 

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

In a view (MVC 3):

<p>Environment.UserName (authentication): @Environment.UserName</p>
<p>User.Identity.Name (asp.net account): @User.Identity.Name</p>

This shows my domain account being picked up as expected (I have to log into the app via the dialog). Great!

BUT WAIT! When the app accesses the file system or a sql server (another machine), it does not do so through my domain account, but rather through the pool account. I can see the SQL login coming in through profiler. I verified this via file system permissions, as well. If I set the pool to use NETWORK SERVICES, I can't create a local file, even through the domain account I'm using has permissions and can do so interactively. If I grant the NS account permission to the files, it works. So I know for a fact that even though the view confirms that I'm impersonating, resource requests don't use that account, but rather the pool's.

If I turn off impersonation, I see the pool ID in view, as expected.

From what I've read I should be able to use basic authentication to access the remote sql server, right? Not to mention the local disk. I just don't get it!

Any suggestions would be much appreciated.

Thank you!

Upvotes: 3

Views: 1954

Answers (1)

Jason Meckley
Jason Meckley

Reputation: 7591

impersonation ends with IIS. to continue passing the user credentials to the 2nd remote server you need to enable delegation between the web server and the file server. This is a bit flag setting between computers in Active Directory.

Upvotes: 3

Related Questions