2

Alright, so, I've been searching online forever, and I can't find anything on this at all.

Basically, what I want to do is run a program from an elevated PowerShell script, but I want the program to run as the standard user.

I need to do this because the program that I need to run requires access to a mapped network drive that the domain administrator accounts don't have access to. So, I basically need a line of code that will take the script out of elevated mode, or some extension to the Start-Program command that will make it run as the logged on user rather than the administrator account that the script is running from.

crimsonnin2
  • 25
  • 1
  • 7
  • 3
    `a mapped network drive that the domain administrator accounts don't have access to` - I don't see how that is possible, or a good idea if it is. But you can use `runas.exe` – arco444 Jul 16 '15 at 08:54
  • It's not up to me who can access what, that's all managed in Active Directory. Standard users can access this mapped drive, and administrators do not, that's just a fact that has to be accepted in this, unfortunately. How would you use runas to make the currently logged-on (to Windows, that is) user open the program? – crimsonnin2 Jul 16 '15 at 09:04
  • Yes, but managing Active Directory and being allowed to access a mapped network drive are 2 separate permissions. What can I possibly be up to by trying to force the user to run the program as a standard user? I'm just not sure as to the syntax of how you'd force it to run as the currently logged in user, rather than the admin account the script is running from. – crimsonnin2 Jul 16 '15 at 09:10

4 Answers4

5

you could use psexec

psexec -l powershell.exe -executionpolicy unrestricted -noexit -file c:\temp\checkelevated.ps1

-l : Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista the process runs with Low Integrity.

Loïc MICHEL
  • 24,935
  • 9
  • 74
  • 103
  • And how would I integrate psexec into PowerShell? I keep getting "The term 'psexec.exe' is not recognized as the name of a cmdlet, function, script file, or operable program". 'cd "\\network\share\PSTools" & psexec.exe -l "C:\Program Files\Program Folder\Program.exe' is the script I am currently using. – crimsonnin2 Jul 16 '15 at 09:43
  • `PsExec` is not part of a system by default, it's 3rd party software from **[SysInternals](https://technet.microsoft.com/en-us/sysinternals/bb545021.aspx)** (which is part of Microsoft now), see [https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx](https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx). – David Ferenczy Rogožan Jul 16 '15 at 09:46
  • @crimsonnin2 try to copy psexec.exe to %windir%\system32 – Loïc MICHEL Jul 16 '15 at 09:48
  • Okay, this is working now, but whenever it launches the program stops responding and crashes. Is this a topic for another question or can that be fixed here? – crimsonnin2 Jul 16 '15 at 09:56
  • maybe you'll have to pass other arguments to psexec this depends on how your program works. You could try `-i` to run as interractive in the user's session – Loïc MICHEL Jul 16 '15 at 09:59
  • @crimsonnin2 What program crashes, `psexec` or `powershell`? Did you try solution with `runas`? It's easy to just check it, maybe it's enough for you. – David Ferenczy Rogožan Jul 16 '15 at 10:00
  • I tried runas before, and it prompted for a user password, which I don't feel should be the case, since the user is already logged onto the computer. Neither psexec or powershell crash, but it crashes the program that I'm trying to launch into for some reason. I checked on the Event Viewer and I'm getting this error: Faulting module name: KERNELBASE.dll, version: 6.1.7601.18847, time stamp: 0x554d7b00 Exception code: 0xe0434352 – crimsonnin2 Jul 16 '15 at 10:04
  • Is your programm running file in low-integrity ? check https://msdn.microsoft.com/en-us/library/bb625960.aspx – Loïc MICHEL Jul 16 '15 at 10:08
  • I just installed Process Explorer to check and it doesn't seem to be running in any integrity? https://www.dropbox.com/s/12eh0jxzxacsmbz/process%20explorer.PNG?dl=0 – crimsonnin2 Jul 16 '15 at 10:23
  • I tried adding -i and nothing changed, just to clarify. – crimsonnin2 Jul 16 '15 at 10:31
  • @Kayasax I just checked running the program normally and it runs in medium integrity. So is there a line of code to make it run in medium integrity? – crimsonnin2 Jul 16 '15 at 10:43
  • I'm affraid you cannot – Loïc MICHEL Jul 16 '15 at 11:26
  • I don't know, usualy you start a script as normal user and elevate when you need it, not the opposite ... – Loïc MICHEL Jul 16 '15 at 11:59
  • That's basically what I've done, there's code to elevate it right at the start, I just want to exit elevated mode before executing this. – crimsonnin2 Jul 16 '15 at 12:01
1

One way that I have used extensively in the past is to create a scheduled task on the fly specifying the currently logged user as the account that will run the task. The task would run some other script, command, etc. and it would occur in the context of the logged on user. This is possible by using Start-Process to call the schtasks.exe program that will...

  1. Create the task (schtasks /create /tn "MyTask" /tr "powershell -file...." /ru "domain\username")
  2. Run the task (schtasks /run /tn "MyTask")
  3. Delete the task (schtasks /delete /tn "MyTask")

You would just need your script to get the current user, which can be done in a number of different ways. I've also put a 2 second pause in between those calls to schtasks just to ensure they all run.

Nathan Tuggy
  • 2,237
  • 27
  • 30
  • 38
Douglas Cote
  • 11
  • 1
0

There are more ways to do it (probably some even better) I guess, but this should also work.

If you need to run an executable or script under currently logged in user from an elevated environemnt, you can use RunAs with USERNAME environment variable passed as user argument:

runas /user:%USERNAME% program.exe

USERNAME environment variable should contain currently logged in user even in an elevated environment.

David Ferenczy Rogožan
  • 23,966
  • 9
  • 79
  • 68
0

The generally intended and accepted way to do this is to specify the network UNC path instead of the network drive. You can even re-map the drive in the elevated process if you need it. That's how you're supposed to do it. If you have an account running a process that needs access to a network location, the proper answer is to grant that account the access it needs to do it's job.

However....

Does this or this or this describe the problem you're actually having? It's very unclear what you're trying to do. You've eliminated all context from your question.

If you're trying to run a script that needs to run elevated and needs to access the user's network drive and you can't use a UNC path for whatever reason, then the above three links are what you probably want.

If you really, truly need to impersonate a logged on user -- and I really struggle to think of a situation where I'd need to do this from a script -- then read on.

The alternatives that don't require knowledge of user credentials are:

  1. Use a user logon script instead of a computer startup script. If necessary, grant the local user the permissions they need to run the rest of the script. I can't imagine you haven't thought of this already.
  2. Create a scheduled task which runs as "Domain Users" or some other group that represents the users in question and the "Only run when logged on" is checked. Again, you'd need to grant the user the permissions they need to run the rest of the script, but it wouldn't tie you down to logon only.
  3. Write a program which calls ImpersonateLoggedOnUser, which requires SeImpersonatePrivilege (Administrators have this by default, IIRC). These are native Win32 calls, not .Net, so they will not be straightforward to use in PowerShell. It's been about a decade since I've looked at this, and it used to be a huge pain because it would sometimes still prompt for credentials. I have to think that the increased security in Vista and later (UAC, et al) would have made this even worse. I also have no idea if you have access to mapped drives (i.e., if the impersonation survives network hops). I would choose this method approximately never.

For anything else, I think you will require credentials of the current user. What you'd be doing is credential hijacking, and OS security is specifically designed not to allow that.

Community
  • 1
  • 1
Bacon Bits
  • 30,782
  • 5
  • 59
  • 66