1

I'm attempting to remote-install a graphics driver on a headless embedded Windows7 system. I have several systems in the field that need repair; I can upload an installer script and execute it as an unprivileged user on those systems. The driver installation requires elevated privileges, however, so I've tried to create a task that will run under a privileged account:

schtasks /Create /XML GraphicsUpdate.xml /ru <username> /rp <password> /tn GraphicsUpdate

This works great when <RunLevel> is set to LeastPrivilege but returns

ERROR: Access is denied.

when attempting to use HighestAvailable.

Attempts to install the driver using the LeastPrivilege run level result in the error "This operation requires an interactive window station," i.e., the UAC dialog; it's hard to click through the UAC on a headless system.

Is there any way to allow an unprivileged user to create a task from the command-line that will run as a privileged user from the command-line at the highest available privilege? Or are there better ways to install a driver headlessly?

Update

Systems in the field run a server that can be upgraded by the user over their LAN (direct Ethernet connection or over wired switch). The subnets I am testing with are exactly the same (e.g., 172.20.81.0/24).

I'd to create a package that will contain the driver and installation script, but the server runs in an unprivileged account. We need to find a solution for escalating privileges from this account in order to install the driver.

0

I'm going to add this as an additional answer because the other one might still help people in a domain scenario.

You cannot do this without having a domain or pre-configuring UAC to allow you to do this. (e.g. https://support.microsoft.com/en-us/kb/951016 )

Microsoft in the name of security has blocked self-escalation outside of the UAC prompt from every way they can think of. PSExec can't work when connecting locally because of loopback protection, and admin shares are blocked remotely by default on non-domain machines. (Which PSExec relies on)

Options that would allow you to do anything in this type of scenario would all require pre-setting something up on the target machine such as Remote Desktop, or the above link.

In a domain environment, PSExec isn't blocked from the network because the admin shares aren't blocked. But outside of a domain environment and without having set something up in person, this is not possible to the best of my knowledge.

  • I was afraid of this! Thanks, though; I wish the news were different, but kudos for the labor—and hopefully we'll have something definitive on ServerFault from here on out. – Ethan Sep 24 '16 at 3:31
0

Try Sysinternals' PsExec

https://technet.microsoft.com/en-us/sysinternals/pxexec.aspx

It can probably be used to do exactly what you're trying to do, specifically execute a process with administrator privileges from a limited account as long as you have the proper credentials.

HOWEVER, while it can be used that way, I'd actually recommend using it instead of a scheduled task to start the installer remotely. That way you don't have to save the password on the remote system.

You can also use it to perform the same task on multiple systems by specifying a text file with multiple computers.

Furthermore, the client computers DO NOT require any special software to be installed. Just make sure you have access to the $admin share and you're good.

  • Thanks, Andrew. I looked into using psexec, but it also denies access: "Couldn't install PSEXESVC service: Access is denied." The user account that I've authenticated is an administrator according to the User Accounts control panel, and I can run applications as administrator as this user. In fact, if I open an elevated command prompt I can run psexec without any issues. But I cannot execute commands remotely or locally this way as far as I can tell. – Ethan Sep 21 '16 at 12:36
  • Interesting. Quick question, are you using a domain for authentication? Or just logging onto a local administrator account? – Andrew Hendrix Sep 21 '16 at 15:51
  • I'll also give you something to try. From your computer on an elevated command prompt (in the folder where you have psexec) try "psexec \\<remote-computer-name> -u <full username like "Consoto\username" or "remotecomputername\username"> -c cmd" That should give you a remote administrator command prompt as a test. – Andrew Hendrix Sep 21 '16 at 16:13
  • Hi, Andrew. This is a local machine, no domain. I've attempted to use psexec both locally in a test bed and remotely from my dev workstation. Following your example for a remote connection, it says "Couldn't access remotecomputername: Access is denied." It'll work locally if I execute psexec in an elevated command-prompt, but not from a limited one. – Ethan Sep 21 '16 at 17:30
  • So, after looking into this a while, and testing different scenarios personally, I think I know the problem. You're not on the same network, and apparently psexec can't be used to self raise in this manner on one machine. (If you had two computers on the same local network, you could pull this off with a little trickery) Do you have a VPN or something? How are you transferring files to and from your remote sites? How are you running a command window remotely to execute your task scheduler? – Andrew Hendrix Sep 21 '16 at 21:26
0

I know this is an old post, but maybe this will help someone else, like me, who was looking for a solution to this same problem.

If this is an option for you in your environment, I found that switching the RunTaskAsUser to the SYSTEM account allowed the task to be imported and, more importantly for me, pushed out via Group Policy.

Importing from the CLI completes without any errors and the new Task is listed in Task Scheduler. Pushing via GPO has the same result.

And this was with leaving the Run whether user is logged on or not and Run with highest privileges options checked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.