3

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!

Jon Egerton
  • 40,401
  • 11
  • 97
  • 129
Todd Beaulieu
  • 627
  • 6
  • 7

1 Answers1

3

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.

Jason Meckley
  • 7,589
  • 1
  • 24
  • 45
  • 1
    Thank you Jason. My impression had been that delegation didn't apply in this case because we were using basic authentication - that IIS would forward a token using the credentials. I found a document from a former employee describing a process that agrees with your statement, but it's pretty deep stuff. Can you explain why even local resources (file i/o) wouldn't take place under the impersonated account? – Todd Beaulieu Dec 19 '11 at 21:10
  • because you are leaving the context of http/IIS. this is by design as it would create a huge security hole to allow clients access to the server beyond the virtual directory. – Jason Meckley Dec 19 '11 at 21:31
  • I've been researching delegation. There are two issues of note: 1. According to a microsoft document (http://msdn.microsoft.com/en-us/library/ff647404.aspx) basic authentication will automatically delegate. I've come across this claim multiple times. This should cover my case, from my view point. Here's a direct quote: – Todd Beaulieu Dec 20 '11 at 15:56
  • 1
    >>Use basic authentication and impersonation. With basic authentication, the user name and password of the user are available in clear text on the server. When IIS authenticates a caller by using basic authentication, it creates a token that contains these credentials. The token can be used for network access. As result, if you configure your application to impersonate the original caller by using the element or impersonate programmatically by using WindowsIdentity.Impersonate, you can access network resources while impersonating. – Todd Beaulieu Dec 20 '11 at 15:56
  • 2. On this same server I have another web app that is configured in the same manner (as far as I can tell) and IT WORKS! I enter my credentials in the same manner and trace it's DB calls, which are made under my account, NOT the pool's service account. I've even pointed my app to that same pool. It's as if I'm missing a setting that's "app specific". I've compared the two web.configs, and they have the same two impersonation settings. I've compared the virtual directoy properties and they all appear to be the same! – Todd Beaulieu Dec 20 '11 at 15:56
  • 1
    I am super close to having this all working. The first problem that nobody ever mentioned was that when Application_Start executes, it's under the pool's identity. Session_Start has the impersonated identity. This explains most of my struggles and wasted hours. The final thing that I can't get working is Windows Authentication through the DNS name. It works through the netbios name. I tried adding the two SPNs to point the machine and fq machine name both to the domain/account used by the pool. No luck. Prompts for the l/p and then fails to delegate, resulting in anonymous. – Todd Beaulieu Dec 20 '11 at 22:01