This code is intended for non-administrator users of their computer so that they can run a task / application as admin So i have created an admin user which i would use to launch app ( with path).

I'm getting an issue when i try to launch an app with the command Runas with another user.

The command requires the user's password to be entered

So i have tried to use :

import subprocess as sub

prog = sub.Popen(['runas', '/noprofile', '/user:kairos', path/of/app],shell=True, stdin=sub.PIPE, stdout=sub.PIPE)
prog.communicate(input=password.encode())

But nothing append. Another way was to use the 'Start-Process' Powershell command with credentials

import subprocess as sub

command = """
    $username = 'kairos'
    $password = 'password'
    $securePassword = ConvertTo-SecureString $password -AsPlainText -Force
    $credential = New-Object System.Management.Automation.PSCredential $username, $securePassword
    Start-Process "path\to\app" -Credential $credential
    """
   exec = sub.Popen(["powershell","& {"   command   "}"], stdout=sub.PIPE)
   exec.communicate()

But this command return "Access denied" despite my user is a local admin of the comput

I have also tried to use this command but im stuck with the UAC

 ctypes.windll.shell32.ShellExecuteW(None, "runas", "path\to\app")

Any ideas ?

CodePudding user response：

• The runas.exe utility can not run processes with elevation (as admin).

• Neither can Start-Process with the -Credential parameter.

• Only Start-Process with -Verb RunAs can launch a process with elevation, and -Verb is mutually exclusive with -Credential.

  • In other words: You can either run as a different user, in an invariably non-elevated process, or you can request elevation, in which case you do not get to choose what administrative user should be used to run the elevated process as.

  • If requiring the user to respond to a UAC prompt (see below) is acceptable, you can use a two-step invocation process, where you first use -Credential to launch a non-elevated process as another use and then request elevation with -Verb RunAs from that process - see this answer.

• Unless you disable UAC - which is strongly discouraged - you fundamentally cannot fully automate launching a process with elevation. One of two interactive actions are always required:

  • If the current user identity is part of the Administrators group in principle: Simple confirmation is required.

  • Otherwise, interactively providing an administrator's credentials is required.

  • The only way to avoid UAC prompts is to either run in an elevated process to begin with or use the following, limited workaround: Assuming that you are an administrator in principle, you can set up a scheduled task with a preconfigured command to be run with elevation, which you can then invoke on demand from a non-elevated session of yours without triggering a UAC prompt - see this answer.

CodePudding user response：

Despite this seems to be a horrible idea for the security of any company trying to do something like this i might have an answer that may lead to your goal. If UAC is enabled correctly, you may not bypass it by any "non hacking method". Your security applications should block applications that are able to do something like that. BUT you may get that application work in background - not in the current user session - if that is enough for you try to start your process with WMI - Use wmic to try https://ss64.com/nt/wmic.html and use "process call create" - Example:

wmic /user:username /password:yourpassword /node:remotemachine process call create "c:\folder\app.exe","c:\folder"

alternative would be to create a "Scheduled Task" or a service that runs with your higher privileges and waits for a trigger. That trigger might be a file created in a folder containing what to do or an entry in application event log. The wait for file change can be notified instantly depending on filesystem handler.

But you must think about security if you are trying to apply that in any company. If you get any unsecure method to work in that your non-admin gets that admin - just in another process - he is that admin and might have multiple ways to use all permissions your "kairos" has. Depending on which application claims to need that administrative permissions you might have many solutions to make that application work with less permissions either. One solution might be to grant the non-admin permissions to the required folders of the application. If the application needs to change e.g. network settings you might grant the user local network operator permissions, so he is always able to change network settings.

Another tip - Never create any program that has hardcoded any kind of password. There are plenty of ways to get that password even from a compiled application. If you need another user, rely on the methods that are part of the operating system (Service with dedicated service user).