vCo 'Run program in Guest' UAC issue

[vpourchet]

Hi all,

I'm struggling on an issue with vCo default 'Run Program in Guest' workflow.

In fact I use it to call Powershell Scripts on a network share since WinRM is not activated on my VMs.

The issue I got is scripts are intended to be run from a 'high privileges' powershell prompt (Right Click -> Run as Admin when using interractive mode), otherwise does not work.

But by default when i start powershell to call scripts using the 'Run Program in Guest OS', apprently it does not use the 'high privileges' mode.

I tried to call a powershell using : start-process -verb runAs -ArgumentList "path to .ps1 file" but doesn't work.

UAC is activated, that might be the issue (when doing start-process -verb runAs -ArgumentList "path to .ps1 file" in an interractive session, i got UAC validation warning pop-up).

Does anybody encountered the same issue regarding UAC / Run program in Guest workflow ?

Any idea about how i could get rid of it ?

Thanks in advance.

Best regards,

Vpourchet

[Burke- · Accepted solution]

Unfortunately UAC DOES block the Run In Guest calls that require elevated privileges. I have not figured out a way past this other than having UAC disabled. This could be acceptable during deployment of VMs to a secure "landing" area of the network, allowing for numerous guest operations to take place, then as a final step, move VM to proper OU to apply Group Policy that forces UAC and then move VM out of the landing zone to its permanent home on the network.

[mcfadyenj]

there is multiple ways to achieve this the simplest method is a third party tool called elevate.

then you simply call

elevate.exe commandline

the alternatives are.

manifesting using run as invoker / always elevate manifests

shimming can do api hooking which will attach an elevate command to the call,.

digital software publisher certs can be used as well but are somewhat more complicated to implement

get a .cer file from a root CA

convert the cer to pvk, then the pvk to spc, add the cert to trusted root on the targets.

if you need more give us a shout.

[vpourchet]

Just a quick update, i choosed to disable temporarily disable the UAC and go for the 'run program in guest os' to :

task #1 - first mount the network drive using a net use cmd

task #2 - then run a 'master script' that contains the operations intended to be performed

the issue i got is that it seems the network drive is not accessible on the second workflow task (#2), even with /PERSISTENT:YES option.

I tried to run a simple powershell script to test if a file on the drive is present (between #1 and #2) and it is not. so i was wondering about the 'scope' of the 'run program in guest OS', knowing it runs tasks async, i added timers but still not works.

Any hints on this ? 😕

[mcfadyenj]

is your net use command using the same account as the task (2).

With uac enabled machines you are having to deal with session based access.

i.e. each user has a session, and some users have two sessions based on the admin access.

when logging into a UAC based machine an admin user gets two user tokens.

1) admin token

2) filtered token

typically all processes run against the filtered token. Think of this like having two users logged into the machine.

items run against the filtered token will not be accessible to the admin token.

therefore if you map a drive using another users credentials, even if you can see that drive mapped it does not mean you have programatic access to the process.

over and above this each process is now managed by integrity levels from a system known as mandatory integrity control (MIC) therefore you cannot context switch between integrity processes or session processes on a UAC box. Depending on what things you are attempting to do even disabling UAC isn't going to solve your issues.

I would highly recommend reading the guide by Mark Russinovich from Microsoft around the Windows UAC.

more than happy to help further if you need more assistance this is an area I play in regularly.

[vpourchet]

is your net use command using the same account as the task (2).

Absolutely. The command is run using the same account but different credentials are used to mount the share drive.

UAC has been disabled using the registry.

[mcfadyenj]

you cannot use different credentials to do this.

this is the session context I was referring to earlier.

Thsi is because the drive mapping is effectively for another user and the cross session security is stopping you.

[vpourchet]

You're right, what i did to bypass this is to start cmd and use both mount and powershell commands in a single command line with '&&' operator between them. Another solution could have be to copy the script onto the VCO server iself and use the 'Copy file from vCo to Guest' workflow but sounds tricky when using appliance (some chmods to be performed on the appliance console). At first i tought there was some 'Copy ressource element' workflow because it's possible to import files this way but ressource elements seems to serve a different purpose.