ApplicationPool user vs StartInfo.Username?

Question

I've been testing ( for the last 4 days) the variety of options to start a Process under iis7 ( asp.net)

I did find a solution.

As long as we don't need to interact with desktop, and only need to run cmd ( or something like that) the solution is simple:

1. w3wp user-> should be high privileged user.

2. Process start info (StartInfo.Username)-> should be also high privileged user.

However, there is a catch ( according to my testings):

Both users have to be the same (if we want cmd to execute)! this is the only way it will work.

So here are my 2 questions:

• Why they both must be the same? Can't w3wp HighPrivilegedUSerA run (via process.startInfo) cmd as HighPriviligedUSerB?

• Both users are domain admins.( which are also admins in my local group). Does only domain admin/local admin can run processes on the local machine?

p.s. All folders permissions are everyone : full controll ( including c:\windows\*.* /s and including cmd.exe permissions) and both users, as mentioned, are admins on local machine with same cloned permissions.IIS7 handler mapping * [static file] is set to read+execute

Also, the full cmd command is:

cmd /c time /t >c:\1.txt. A success is if the file exists.( and I succeed, only when both account were the same).

Full code:

Process proc = new Process();
  proc.StartInfo.FileName = "cmd";
  proc.StartInfo.UserName = "Royin"; //<-- only if this user is the same as w3wp user , the operation succeed !
  proc.StartInfo.Domain = ...;
  proc.StartInfo.WorkingFolder = @"c:\windows\system32";
  proc.StartInfo.Password = ...
  proc.StartInfo.Arguments = @"/c time /t >c:\1.txt"
  proc.Start();

Answer 1

Ok, first, I HIGHLY recommend using the excellent SysInternals ProcessMonitor to help troubleshoot any issue like this: Process Monitor.

This app will basically tell you every action a process is attempting to take, so in your situation, you'd see it try to call QueryOpen, ProcessCreate, etc.

Have you checked what the ExitCode of the process is under the failing scenario? I'd be willing to bet real money it's coming back as 0xC0000142 (-1073741502), which means something like "failed to load DLL" or something. Running anything under the system32 path, even with privileged user credentials, is going to run into oddball issues with permissions, again due to the initialization procedure for creating a process.

Basically, the Process.Start flow looks something like this:

(assumptions: UserA == process running w3wp, UserB == impersonation ctx, UserC == credentials specified in process start info)

1. First, UserB isn't going to have much impact, as we've discussed in other conversations; any process creation stuff is going to be based on the process token of the "launching entity", so the credentials of UserA are the ones we'll be looking at.

2. The runtime says "Hey, can UserA access the file name specified in StartInfo.FileName?"

3. Windows responds yes/no, but also "BUT, to use that, you also need to be able to read all these other DLLs"

4. Runtime responds "Ok, can UserA access those DLLs?"

5. If the answer to all the above is yes, then the runtime says "Ok, logon this user and try creating a new process with cmd line and arguments..."

You are most-likely running into issues with either #2 or #4, as the default app pool identity has no read-access rights to the System32 folder. This is why when you switch the identity of the w3wp process to a privileged account, it works.

You could try a couple things, but the easiest option is probably switching back to a low-privilege account (like default app pool identity), but grant read-only access to the system32 folder to that account.

I would ABSOLUTELY not run w3wp as a privileged user, though - that is just asking for massive headaches should anything nasty happen, like somebody hacking you.

Oh, last thoughts:

• DON'T set UseShellExecute to true if you can help it, it does weird stuff.

• DON'T set LoadUserProfile to true if you can help it, it also does weird stuff, and is really slow as well.

• DO set CreateNoWindow to true if you can, otherwise you'll see lotsa windows opening/closing on the server

• DO use RedirectStandardOutput / RedirectStandardError instead of piping the output, it's way more controllable and gives better feedback when things go wrong.

• DO always check the ExitCode of the process if it doesn't look like it worked