ASP.NET refuses to respect my authority.

Question

I've managed to impersonate a user successfully. Using the LogonUser Interop, e.g.

    [DllImport("advapi32.dll", SetLastError = true)]
    static extern bool LogonUser(
      string principal,
      string authority,
      string password,
      LogonSessionType logonType,
      LogonProvider logonProvider,
      out IntPtr token);

This works fine. When I go to my immediate window and enter WindowsIdentity.GetCurrent().Name, the impersonated user shows as my CurrentUser. When I release this user, it goes back to my real user. No problems here -- I'm am impersonating.

However, when I attempt to write a file to a share that the user has access to, I get:

Access to the path [path name] denied..

I've been able to log into Windows manually as the user I am impersonating, navigated, and written a file to the share. The user definately has administrative privlidges to the directory I'm targeting.

I am allowing the end user to upload a file, and using the HttpPostedFileBase object, write a file to this share. Essentially, I am restricting the impersonation to the block of code to upload the file. Once it's finished, it goes back to the original authenticated LDAP user e.g.

 imp = Impersonation.ImpersonateUser("someuser","somepassword");
 HttpPostedFileBase hpf = Request.Files[file] as HttpPostedFileBase;
 ...
 hpf.SaveAs(path);
 Impersonation.StopImpersonating(imp);

The path is correct.

When I save the file using the SaveAs method, is it respecting my impersonation?

Is it attempting to write the file under another account I'm not aware of? And if so, how can I change this?

There doesn't seem to be a whole lot of control using the SaveAs method -- not a single overload. Are there any other alternatives to using this object that would give me greater control over my credentials?

Answer 1

It sounds like a double-hop authentication problem. Have you tried getting giving the network share modify access to your site's default IIS user (e.g. ASPNET) and run the POST/SaveAs without the impersonation code at all? If that fails, you should look to see if things are setup in IIS that can lead to server hop authentication issues. Here might be a good place to start:

http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx