Reputation: 21
After reading tons of similar posts I decided to came up with this one. Well, basically this problem is similar to many others, but somehow I can't make it work.
Here's the scenario, I have load balancing over 2 servers (servA and servB) and I need to force the app to create just on 1 of them. So I want to put the UNC path when I save files. I, obviously, have a problem creating files on the directory over the net.
If I run it with Cassini it's all good, I can access to the path cause it's logged with my account. As soon as I migrate the app on the development server it doesn't work anymore.
I know IIS uses the user associated with the app pool, so I checked that account (which is network_service) and added write privileges write on that folder.
Still not enough. What you think on "Everyone"?! It must work!
Oh, well, it's not.
Let's see some code:
Directory.CreateDirectory("\\\\my.ip.over.da.net\\c$\\inetpub\\wwwroot\\projfolder\\otherprojfolder\\test");
And this is the message I got when I try to create that folder.
{"Message":"Access to the path \u0027\\\\\\\\my.ip.over.da.net\\\\c$\\\\inetpub
\\\\wwwroot\\\\projfolder\\\\otherprojfolder\\\\test\u0027 is denied.","StackTrace":"
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)\r\n at
System.IO.Directory.InternalCreateDirectory(String fullPath, String path,
DirectorySecurity dirSecurity)\r\n at System.IO.Directory.CreateDirectory(String path,
DirectorySecurity directorySecurity)\r\n at
NSC.Ajax.GetData.testgrid()","ExceptionType":"System.UnauthorizedAccessException"}
It's called via AJAX for easier testing, this is why the response is formatted that way.
Upvotes: 1
Views: 12497
Reputation: 1817
The problem is you're not going to have access to that location using the IIS credentials, the dev server is going to be on a separate domain somewhere else, and accessing back to your machine going to the c$ admin share isn't going to work, changing permissions at that level is.. a bit risky...
If you really have to access files on your local machine from your dev server, you'd probably be better off creating a share called test
(C:\inetpub\wwwroot\projfolder\otherprojfolder\test
) on your machine and set the permissions on this for Everyone
to read (if you're going to need to create files and folders you'll need more, but I'd suggest only giving the minimum access you can get away with), pretty insecure though, but since your dev machine won't have any way of authenticating an account on a different network (your machine you're sharing the files from) you don't have much to play with!
So create a local shared folder, then just point your code to \\\\my.ip.over.da.net\\test
.
Note, you'll need to set the permissions on the share and on the folder itself, if the share has enough permissions but the ACL on the folder doesn't agree you'll still get permissions denied.
Upvotes: 2
Reputation: 5244
You can impersonate a different user when creating the directory
public static void CreateDirectory(string myDirectory)
{
SafeTokenHandle safeTokenHandle;
bool returnValue = LogonUser(@Username, @Domain, @Password, 2, 0, out safeTokenHandle);
if (returnValue == true)
{
WindowsIdentity newId = new WindowsIdentity(safeTokenHandle.DangerousGetHandle());
using (WindowsImpersonationContext impersonatedUser = newId.Impersonate())
{
System.IO.Directory.CreateDirectory(myDirectory);
}
}
}
[DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
public static extern bool LogonUser(String lpszUsername, String lpszDomain, String lpszPassword,
int dwLogonType, int dwLogonProvider, out SafeTokenHandle phToken);
public sealed class SafeTokenHandle : SafeHandleZeroOrMinusOneIsInvalid
{
private SafeTokenHandle()
: base(true)
{
}
[DllImport("kernel32.dll")]
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
[SuppressUnmanagedCodeSecurity]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool CloseHandle(IntPtr handle);
protected override bool ReleaseHandle()
{
return CloseHandle(handle);
}
}
}
More details here : http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx
Upvotes: 0