Reputation: 32258
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?
Upvotes: 14
Views: 691
Reputation: 6295
Try adjusting your LogonSessionType value. I think in order to save to a network share, you need to have it as "Network", while the default is "Interactive".
Further details: How To: Use Impersonation and Delegation in ASP.NET 2.0
Upvotes: 0
Reputation: 630
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:
Upvotes: 3
Reputation: 8562
You say "write a file to this share." There are separate permissions for the share than there are for the folder on the computer. Have you checked the shares permissions?
Upvotes: 0