Say you have a process you want to periodically kick-off on a machine somewhere. And say you want to make that process available to people through a web interface, so they don’t have to schlep to a particular PC somewhere in the cube farm. And to make it as challenging as possible, your process needs to have the network credentials of the person kicking off the service.
This is a substantial challenge. Before you think impersonation will take care of the problem (as I initially did), such is not the case. While it sounds like this is fixed in ASP.NET 2.0, any launched process from a web app will be launched under its parent process (by default, the ASPNET user). You can impersonate a user to the web site, but those credentials cannot be passed beyond the app domain. They just can’t.
There are 3 steps needed to make this work. First is to Pinvoke the CreateProcessWithLogonW Windows API call, so that a domain user can log onto the web server machine and run the process with the proper credentials.
[DllImport("advapi32.dll", CharSet=CharSet.Auto, SetLastError=true)]private static extern bool CreateProcessWithLogonW(String lpszUsername, String lpszDomain, String lpszPassword, int dwLogonFlags, string applicationName, StringBuilder commandLine, uint creationFlags, IntPtr environment, string currentDirectory, ref StartUpInfo sui, out ProcessInformation processInfo);
More information on this call is available here.
It can be a lot of work to make this work correctly with the structures required, so I found this wrapper class to work great! In fact, this wrapper class made all the difference in my particular application.
http://www.thecodeproject.com/csharp/RunAs.asp
As you may notice, one of the downsides to this is providing a network password to the class to complete the logon. As of right now I can find no way around this, and it is certainly more secure than passing a command line parameter to an application. Something to consider.
There are two modifications that are required to make this class work in this application. First off, in my particular need the process I was launching was a console application. This meant interacting with the desktop. It also meant the logon process had to specify a desktop to log into (which I didn’t know you had to do, thought you just logged into a machine with a particular account). If you do not specify this, you will receive the following message as soon as the new process starts (you will not hit your code, so there is no trap for it):
The application failed to initialize properly (0xc0000142). Click on OK to terminate the application.
To identify the default desktop, modify one of the overloaded “StartProcess” methods in the RunAs.cs module.
startupInfo.lpDesktop = @"winsta0\default";
http://channel9.msdn.com/ShowPost.aspx?PostID=7205
(read the LAST comment)
One final note in the RunAs.cs module, by default you are performing a full logon into the host machine, which will include creation and copying of a users profile. While it will take up additional disk space, it takes fricken forever, especially by web standards. To disable this, change the LogonFlags parameter of a “StartProcess” method to LogonFlags.NetworkCredentialsOnly.
This completes step 1 of 3 to make this work correctly. The last two steps are relatively easier.
Step 2, you must grant special permissions to the web assembly so it can use Pinvoke. If you use impersonation, this won’t be as much of a problem as “users” generally have this privilege. Use the .NET Framework Configuration tool to create a Run-Time Security Policy, granting the Security privilege, with the “Run Unmanaged Code” option enabled.
Step 3 was a bit more challenging a concept. As you would expect, the ASPNET user needs to access the executable, so you would grant permissions to that user to read and execute from the directory where the process application lives (I would strong suggest a different directory than your web application). But remember, someone other than a machine user will be logging on and running this application. You need to grant the Domain Users group access to the directory as well.
The hard part about doing this is it is an all-or-nothing operation. You have to do it all or none of it works. It’s also a good idea to complete development as a non-machine administrator, as that will mask many of these problems until deployment. I am sure as I continue to refine this body of code I can cut parts out and trim it down. Hopefully ASP.NET 2.0 will simplify the process.