Integrated Windows Authentication breaks File.Exists

Question

I have run into the wierdest issue, and I'm hoping some ASP.NET expert can give me some clues as to what is going on.

I have an ASP.NET Website running on IIS 6.0. On it, I have an .asmx webservice. In the .asmx webservice, I use System.IO.File.Exists() to check if a file exists on a network share. The site uses Impersonation.

Here's the massive kicker: If I set IIS to run the site using Basic Authentication, the File.Exists line returns True. If I set it to Integrated Windows Authentication, it returns False. I change nothing else, i can change back and forth and the exact same thing happens. I'm logging some information before the call to File.Exists() and indeed, both User.Identity.Name and System.Security.Principal.WindowsIdentity.GetCurrent().Name return the exact same name regardless of setting (my own account which obviously has access to the files I'm looking for).

I would post things I've tried but honestly, what can you try in this situation, where one setting which shouldn't affect the issue is the problem. I have tried turning impersonation off, and that also makes the File.Exists() call return True (which is blowing my mind since my own user has far higher permissions than the account running the appPool).

Any ideas what I can look into to get this issue resolved?

Answer 1

OK what is happening is that the server is not able to delegate the authentication. That is, it cannot act on behalf of the user to another server, only to itself.

Delegation is not a problem for Basic authentication because the server knows your password (because you told it as part of the basic authentication), so it can perform authentication to the remote computer.

If you are in an Active Directory/Kerberos environment, you must configure the server to be trusted for delegation . I have never had to do this so I am not sure exactly how, but it is a matter of configuration, not programming. You may have to configure the Server machine account, or the IIS identity or both, depending on your configuration.

See here for some references:

• http://technet.microsoft.com/en-us/library/cc739474(v=WS.10).aspx

If you are not in a Kerberos environment, you must either use basic authentication, or get the password from the user in some other way, and call LogonUser yourself to impersonate the user. If Basic authentication is used or a clear-text password is used in any other way, you must of course use HTTPS/TLS for security.