1

On my personal Win7 machine, my user account is a standard account, and there is also an Administrator account which I obviously control. One app that I have start up with Windows needs admin privileges to work correctly. It's AIDA64 sidebar, in case anyone is curious.

I've searched this site, the web, and the AIDA64 support forums for ideas on how to make it work, with no good results. I've scheduled tasks for it to start up under the admin account, but in that case it never even shows as running for the standard user (although if the standard user launches it manually "as admin" then it works fine). Alternately I can schedule it for the standard user with "highest privileges" which I've seen recommended dozens of times, but that does not work, since it uses only the user's highest accessible privileges, and not the admin's, even if the admin is the one scheduling the task!

The closest thing to a real solution I've seen is to use runas /savedcred in the scheduled task, but that is a huge security hole that nobody recommends. If that is the only way to do it, I'd rather just make my user account an admin and be done with it.

I know there are a lot of security options that I'm unaware of or have never used. I'm hoping there is some way to accomplish this that I haven't considered yet.

2 Answers 2

1

There are several ways to run the app

  1. Open CMD as Administrator and move to directory where app is stored and try to launch the app Via cmd shell

  2. Again open cmd shell as Administrator and use PsExec to launch the app using different admin account and look into processor explorer if app is launched in different session ( i am assuming you will create other admin user on your machine)

  3. Try to launch the App with Elevated token using PsExec -h Option from admin cmd shell if it works, then the app will also launch from Default Administator account of your machine if it is enabled in compmgmt.msc

  4. using the same elevated cmd shell try to launch the app in session 0 see if it works using Psexec -s -i 0 app and look through process explorer if it is actually launched

  5. you can also try and launch the app in your current session under system account and see if it works

  6. you can also use psexec to launch the app under user privilages from your admin shell using psexec -u user -p password option and see if it is launched

Also try At option of taskschedular to launch your app and finally you can use processor explorer > options >select coloums > view commandline to see exactly which command the app uses to launch when it is launched under administrator as you said, then you can use same command to launch the app, with this you can also debug why the app is not launching using task schedular and learning from processor explorer

1

The at /interactive method seems to be optimal, but it only allows to schedule a task at specific time. If you want some sophisticated launch criteria, or run a task at a user logon, it won't make it. The best solution I've been able to achieve is as follows:

  • download PsTools: https://technet.microsoft.com/en-us/sysinternals/psexec.aspx, unzip, add directory to the %PATH%,
  • create a batch file:

    @echo off
    for /f "tokens=3 delims= " %%a in ('qwinsta ^| find /i "active"') do ( set SID=%%a )
    PsExec.exe -i %SID% -h %*
    

    You may have to replace 'active' with your localized term, if you have localized Windows version (eg. in Polish Windows it's 'aktywna'). Simply check it with qwinsta. This batch file determines the SessionID of the active session and runs a command with current user's credentials, but in the session of detected SessionID.

  • run the task scheduler as admin and create a task. Set it to run as admin with elevated privileges, independent of user being logged in. Set the desired criteria for running the task. Set the action to run your batch file, and set the parameters string to:

    -d -u admin_user -p password yourApp.exe
    

    If your app is a CLI one, omit the -d. User and password of account which is used for the task have to be supplied, otherwise GUI apps won't work correctly (I don't know why; maybe CLI apps will work OK, I haven't checked). Instead of supplying user and password, you can give the -s switch, but then your app will run with local system account.

The effect of running the task is similar to right-clicking an executable and selecting 'run as administrator', but without UAC popping up. This way, once you have created the batch file, you can easily create next tasks, and the batch will make them run in the active session. The security probably isn't perfect this way, unless your users are trusted, but at least your admin password isn't stored in clear text inside the batch file, and also the task itself isn't visible to regular users. To make the security a bit better, you can make both the batch file and the target executable unavailable to the users other than admin. And you need to make sure that noone has a login containing 'active' or any word used insead of it by your local Windoze version - or you will have to reforge the batch and add another for, making it complicated (or use PowerShell or UnxUtils).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .