Permissions Issues: Process.Start() & XCOPY

[Matthew Lee]

I am using a C# / ASP.NET application to fire an XCOPY job from the
webserver to a UNC share. This setup works fine when copying to a
local machine but refuses to work on the remote copy. The process
executes correctly, but XCOPY returns "invalid drive specification",
which I'm guessing actually means that the current user context
(ASP.NET application) can't access the share (e.g.
\\someserver\c$\mydir\)

Anyway, here's where I'm at with permissions:

* Changed the ASPNET account to run as System in machine.config
(reboot)
* added
<identity impersonate="true" userName="MY_DOMAIN\\administrator"
password="xxxx" /> to web.config

* Interesting note: when I display the current uiser the ASP.NET app
is running under, I get MACHINENAME/Administrator, not
DOMAIN/Administrator. This seems wrong?

Other examples on the web seem to indicate that this is an issue with
System.Diagnostics.Process, in that it incorrectly uses the user
token, blah blah, (i.e. a bug in .NET). System.Diagnostics.Process
doesn't have the capability to supply user credentials to the process
it runs (a somewhat ridiculous omission)

Any ideas here? TIA.

- Matt

 

[bruce barker]

with NT when you start a process, it inherits the security context of the
starting process (aspnet.exe) not thread (also ignore impersonation). you
can have asp.net run as a domain account rather than system. to skip this
look at CreateProcessAsUser, which allows starting a process as a different
user.

-- bruce (sqlwork.com)

 

[Matthew Lee]

with NT when you start a process, it inherits the security context of the
starting process (aspnet.exe) not thread (also ignore impersonation). you
can have asp.net run as a domain account rather than system. to skip this
look at CreateProcessAsUser, which allows starting a process as a different
user.

I actually tried some C# interop classes I found on the ASP.NET site,
they use LogonUser from the W32 API, but it still does't work.

Just to clarify:
* if ASP.NET is configured to run as SYSTEM, then why is there an
issue? Wouldn't the "security of the starting process" now be the
System account?

* therefore it would be correct that impersonation as I understand it
only applies to the ASP.NET application itself and not processes
started by the ASP.NET application?


If the above are true, then how is it possible *AT ALL* to launch a
process as a user without resorting to API calls?

I've spent 2 days on this and it's obviously a common problem.

Thanks for your help.