Running Scripts with Administrative Privileges Through an SBA

A user asked about running a script with administrative privileges through an SBA. It was confirmed that the SBA runs in the system context on the remote machine, so administrative rights should already exist. A workaround of utilizing scheduled tasks was suggested, however the user mentioned that this was too complicated to get through their security team, and proposed the option to use shared credentials. It was mentioned that shared credentials can be used while copying files and to utilize a service account with admin rights when performing software installations.

Read the entire ‘Running Scripts with Administrative Privileges Through an SBA’ thread below:

Anyone know if there is a way to run script based actions with Administrative privileges? I am trying to install the Horizon agent and other components through a SBA but have run into a wall as the script is running in a non-admin shell.

By default the SBAs run in the system context on the remote machine.

So you should have admin already.

was just getting the screen shot lol

local system will not always work sometime i have to use a service account in the shared credentials

Great! I did some testing and can confirm that when the Security Context is set to "Default (Local System)" the shell is created in the Administrative context. When I tested with a variety of service accounts/user accounts that have administrative rights the shell is always opened in the user context. Anyone had any luck using a shared or prompted credential to execute a script in the admin context?

if you need to run the script in the user context i think u will need to use the default local system and user needs local admin rights. you could do the script in two folds 1. use a script to raise the logged on user to local admin. 2 run the other script to do what u need and the use a script to drop the rights again. but

Can you self-elevate your script?

https://learn.microsoft.com/en-us/archive/blogs/virtual_pc_guy/a-self-elevating-powershell-script

never tried it

Looks like UAC would be an issue though. Which is probably the whole root of the issue to begin with actually.

Got this when attempting to self-elevate.

I agree with Dennis on this one, I believe it is attempting to spawn a UAC prompt but is unable to do so due to it being a non-interactive shell

My workaround for scripts like that in the past is to use scheduled tasks to run the script but that requires hard coding login information in the scripts which has it’s own concerns of course. The one that I still do this with the account is not a member of the Administrators group until the launch script that creates the scheduled task adds the account. The script that runs, then removes the account from local admins. It’s a patch work, but again, it works for the specific use case.

That’s quite a workaround and not likely one that I could get by my Security Team. Seems like a feature needs to be added that allows for an elevated script to be run by a saved credential account.

Saved credential? Like Shared Credentials?

I’d vote for that on User Voice. Not sure how they work around UAC, if it’s possible, but Scheduled Tasks do it, so there may be a way.

Not sure if this option would change anything…

Yes I have used the option to utilize shared credentials while copying certain files from a shared drive to the VDIs.

This option to utilize shared credentials came in very handy…

Now for installation of agents I have also tried using SBA to upgrade VDA agent.. but sometimes did run in to issues with switching context. However, if you would use a service account that has admin rights on the VDI as well that will help a lot in elevating permissions required for performing such installs.

Continue reading and comment on the thread ‘Running Scripts with Administrative Privileges Through an SBA’.  Not a member? Join Here!