I am looking for away to run batch files in elevated mode (runas administrator) so that it doesn't trip the UAC to prompt for user interaction. We have some registry edits, among other things, that we do in our login scripts which trigger the UAC to prompt for each registry that is run.
I realize that this sort of defeats the purpose of the UAC, but it would be nice if there was some way of running batch files on machines that have UAC enabled.
These batch files need to be able to run without any user interaction (they are mainly login scripts, and some administrative scripts). We are not using an Active Directory domain, so hopefully there is a solution for none AD domains.
The solutions that I have found so far are as follows:
Disable the UAC altogether - We normally do this, but we might be running into some situations where we cannot disable it.
Create a shortcut to the batch file we wish to run in elevated mode. Go to the properties of the shortcut > Shortcut tab > Advaned > Check off "Run as Administrator"
This solution seems to work, however the initial running of the shortcut causes the UAC prompt to come up. All the commands run within the batch file do not cause the UAC prompt. Close to the solution, but it would be nice not to get any prompts.
3.
Running the batch file with the 'runas' command.
I have tried this, however it still doesn't see to achieve the elevation to prevent the UAC from prompting.
Also, using the echo 'password' | runas ..... method to provide the password doesn't seem to work right, so I am always having to type in the password.
The other thing that I was thinking, but I haven't really researched yet is, do powershell scripts run/work better in an environment where the UAC is enabled? Does Windows 'trust' certified powershell scripts and allow them to run unimpeded without triggering the UAC?
From what I have read, these is no way around the UAC other then disabling it. But I just wanted to see if anyone might be able to shed some additional light on this topic.
Thank you,
Cheers
There is no official way to by-pass the UAC prompt for your application. There are a few ways to run a program as administrator if you have the account password (same as the runas approach).
you can use the following Power-Shell script to start your program as administrator without asking the password:
You'll need to save the user password somewhere as a secure string:
$pass = Read-Host -AsSecureString
ConvertFrom-SecureString $pass | out-file pass.txt
Then you can run the file as administrator with the stored password this way:
$pass = import-SecureString (get-content pass.txt)
$startinfo = new-object System.Diagnostics.ProcessStartInfo
$startinfo.UserName = "administrator"
$startinfo.Password = $pass
$startinfo.FileName = "your batch script file name"
$startinfo.UseShellExecute = $true
[System.Diagnostics.Process]::Start($startinfo)
Registry manipulation for which the current user has access will not itself trigger a UAC prompt.
However using an application with a manifest that requires elevation if running as un-elevated administrator will prompt.
Are you trying to use regedit.exe to perform batch operation? If so replace with reg.exe (using cmd.exe) or, better, PowerShell's inbuilt registry support.
Eg.
get-itemproperties 'HKLM:\SOFTWARE\Classes\Folder'
will not require elevation (as that key is readable by everyone), but setting a property on that key will require an elevated PSH session.
An alternative approach, if you are performing operations that require administrative access (need modify access to some object with ACL that limits modification to administrators). Or, something a non-administrator could never do UAC or not, without enter an administrator's account's credentials.
Consider using Task Scheduler: a trigger of on user logon but configured under a specific elevated administrator account.
Summary: really need to know at least one of the things you are doing that triggers UAC in detail.
Setting up a scheduled task that will run elevated needs one consent once when you set it up, and never again. Since you mention these are login scripts, a scheduled task that runs on login should meet your need perfectly.
Related
I currently have a huge number of VBS Scripts which are, when doubleclicked in Windows Explorer, run by wscript.exe. These scripts need to be run in UAC elevated mode, i.e. doubleclicking by default will not work.
One solution for this would be to alter all the scripts, and make the scripts run themselves elevated, this solution can be found on many places, but Altering all the scripts is a tedious work.
So I am currently thinking of another solution to alter the default Shell Extension behaviour in Windows 10, so that wscript.exe will always be started elevated wenn a vbs script is doubleclicked in Windows Explorer. The problem is that I currently cannot find any commandline option that I can pass to wscript.exe to run it elevated.
Is there any solution available to call wscript.exe always in elevated mode? The scenario that should work is that a user can doubleclick the .vbs-file in Windows Explorer, and then automatically be prompted with the UAC-elevation dialog (if configured in Windows)
You can use Task Scheduler to run your script as an administrator without having to go through User Account Control (UAC) every time.
You can run scripts as administrator with the runas verb, but the user must have admin rights on the machine to do so.
You could store admin credentials in the script, but it would be plain text and not secure.
Run elevated commands only work on machines where you have local admin privileges. Other non admins can't use the script.
I want to create PSSession on remote machine with administrative rights,anyone knows how to do that.
I have notices even i know administrative credentials, and using same while creating a PSSession, don't let me execute some commands on that remote machine.
I have searched, and found even using administrator credentials at PSSession don't create my session as administrator.
any idea how to do that or even how to switch session?
This is a very good question.
Your problem, as you probably know, is caused by having UAC turned on, on the remote machine. This means, that even though you are running PowerShell session as user who is a member of the Administrators group, your PowerShell session is not executed with elevated privileges.
If you execute a script localy on the server, there is a way to automatically elevate privileges within the script. This is explained here.
A self elevating PowerShell script
Unfortunately for you, this still creates a popup prompt for user to accept the privilege elevation. This makes it completely useless for remote execution.
I know that a lot of people will probably disagree, but the best (and possibly only) solution is to turn UAC off on the target machine.
My question is basically identical to this unanswered question: How to run an application as "run as administrator" from the command prompt?
I am working from within the Oracle Enterprise Manager, setting up a "user-defined metric", and using the "execute host command" feature to test things. In both cases one provides a single line that is fed to the command processor on the remote machine (Windows 7). The account on the remote machine is a machine-level account in the administrators user group but is not "administrator". I do not have access to the "administrator" account password. (I am a consultant working in an environment administered by the client.)
Logged in interactively on the remote machine, the account I am using can "run as administrator" a command window without supplying an administrator password, and can run my script successfully. I looked at the "runas" command and tried it out but I could not find a way to use it without supplying the "administrator" account password, which I do not have. The person who posted the other question (above) said he tried the /NOUAC and /elevate options with no success. I have not tried them.
FWIW, the command I am trying to run is a PowerShell v 2 one-liner that gets one WMI value.
Anyhow, it may be that what I am trying to do is by design impossible within the UAC world -- to do these operations one either is an administrator-group user working interactively or one is the administator.
create a batch file with following lines
start
and save it an a location of your choice.
Then right click on the batch file and select "Run as administrator" This would create a command prompt
as administrator
I have made a power shell script which loads pageant (a windows SSH authentication agent)
with my private keys. In short the script isn't much more than the following two lines:
$tool = "pageant.exe"
&$tool $files.ToArray()
$files is a list of strings which contains all my private keys which must be loaded.
I have no problem with the working of the script because it does its job perfectly when I execute this from my powershell
console.
I want to execute this script whenever I logon to my account and I do this by adding a powershell logon script
group policy with the group policy editor (gpedit.msc), the script also executes and in fact does load the pageant.exe tool.
However the tools utilising the pageant.exe tool (putty and plink) does not work. It doesn't recognizes the pageant authentication
agent.
So my first question is, what is the difference between starting the script from my own powershell console and starting the script
from a group policy (logon script)?
I also have dome some investigation and I see a couple of differences. The first is thing is that the started pageant tool has a UAC Virtualization flag in my task manager when I start the script from my own console. This property isn't flagged when it's started
from the logon script group policy.
The second thing is that when I disable the UAC the script does work from the logon script group policy. So I assume it has something to do with the UAC but I don't know how to solve this. I want the script to work when the UAC is
enabled as well.
The second question what is this UAC virtualization flag and how does it influence the working of a process? The third and last question is how can I get my script working?
It looks the thing is UAC virtualization. This flag means that all write attempts to protected system areas are redirected to VirtualStore in the user's profile: C:\Users\<username>\AppData\Local\VirtualStore. When UAC is disabled, this redirection is turned off.
When UAC is enabled, any attempts to write to Program Files, as an example, will be redirected to the corresponding directory in your VirtualStore. Later when programs read the files, they also see them from the redirected directory.
Yet your logon script runs without Virtualization enabled, and therefore its attempts to modify/read files do not go to the redirected VirtualStore but rather directly to Program Files.
So you have to make all your parties work without virtualized directories. If the executable has a manifest, preferrably declaring compatibility with Windows 7, then virtualization is turned off. But it may fail to work correctly without virtualization if it tries to write to Program Files.
Note: registry writes to HKLM are also virtualized.
There are a number of ways to turn off UAC virtualization; the simplest is to include an external manifest (in your case it would be named pageant.exe.manifest) in the same folder as the exe. This could suppress elevation, but then your writes would probably fail. The very fact that virtualization is affecting you means that pageant.exe must write to protected areas, and without virtualization or elevation, you'll get access denied.
Therefore what I would do is leave Group Policy out of it. Set up a Scheduled Task (click Start and type Task to launch task scheduler, then click Create Task on the right) that runs at logon (the Trigger tab, click new, change the top dropdown) to run your script (Actions tab, click new) and that runs elevated (General tab, check Run with highest privileges). You'll have to consent once to the UAC to set up the elevated task. Then you're done and pageant.exe will write to the protected area where the other apps can read it.
If, after you've got this set up, the other apps continue to read from the virtual store instead of the real one, just delete the files/folders in the virtual store.
For completeness I added the answers to my own questions.
What is the difference between starting the script from my own powershell console and starting the script from a group policy (logon script)?
A: The difference comes from the fact that my user is part of the Administrator group which will run the script with elevated rights. When you logon as a administrator, Windows will generate a standard user access token and a administrators access token. The last token will be used to run programs with elevated rights (this is without UAC virtualization). Now when I start the script from my own powershell console, which is started with the standard access token, the started pageant is run with UAC virtualization. If the tools which use pageant run with a different mode, then my problem occurs.
What is this UAC virtualization flag and how does it influence the working of a process?
A: Check out this link.
How can I get my script to work?
A: You can use the solution provided by Kate Gregory (do not check run with highest privilege option) or add a batch file to your startup folder which runs the powershell script. This will run the script with the standard user access token and with UAC virtualization enabled.
This question already has answers here:
Disable Vista UAC per-application, or elevate privileges without prompt?
(3 answers)
Closed 9 years ago.
Is there a way to get my .exe file to execute with administrator rights instead of me
killing the LUA at registry or right click file and running as administrator?
When I alter the registry it prompts the user which I don't want. I am only adding the file to kill the LUA to give the user full rights to execute my .exe file.
If I can just get it to execute as administrator it would save me editing the registry. I can't find the source code for the application. It is coded in Delphi so it is a problem to add anything and the .reg file needs to be run with the .exe files on Windows Vista.
How can this issue be resolved?
You can't. If you could do it, any exe could to it and that would defeat the purpose of the UAC (assuming arguendo you believe there is a purpose for UAC). You can manifest your exe to require administrator privileges, but that will not stop the user prompt.
There are two proper ways to do this:
As already noted mark your exe as requiring elevated privilleges - the user will be prompted when starting your program, administrator privilleges and user confirmation are required.
Create a service running as LocalSystem that is allowed to do anything without prompting the user. In this case you have to implement interprocess communication mechanism for the service to communicate with user UI program, which may not be trivial. For this scenario your program has to be installed by administrator, but after that may be used by anyone - this is common for corporate scenarios.
Generally speaking Vista compatibility may not be easy to achieve and depending on your software may require a lot of work.
I'm not able to test this since I've only got XP with me at the moment...
Try creating a batch file with the runas command in it.
Note that the password will still need to be entered but it may save a couple steps.
If you just want to avoid the right-click and run as admin you can rename the exe to something like xyzSetup.exe.
There is (hopefully) no way that you can bypass the prompt, otherwise anyone can do it.
If you are just trying to avoid repeated prompts and don't mind being asked for the password or permission once, you could use runas with the /savecred option.
Generally this problem is solved by installing a Windows service which runs as SYSTEM or an administrator account. Then your application can request the privileged action from this service.
Obviously to not pose a security threat ensure that your service can't run arbitrary code or something which might leave the all users vulnerable to privilege escalation attacks.
WinPcap and most of the other sniffing applications use a similar design to give sniffing access to unprivileged users.
Install your service during the first run (or in the installer, which will require an UAC prompt).
I will have to read up on this but I don't have access to my source so this would be a problem.