I would like to run an executable as a different user in ant on Windows. I was thinking of invoking PsExec to run on the same machine and passing in a username and password. Is there a better way to do this? The answers I have found so far are for running ant on Linux/Unix.
Thanks.
You can use the runas utility to run an executable as a different user.
Allows a user to run specific tools and programs with different permissions than the user's current logon provides.
In windows versions previous to Windows 7, you should be able to simply right click on the executable and select "Run As". You can then select the user from a drop down list of available users.. In Windows 7, this option has been replaced with the "Run as Administrator" option.
From the windows pages at Microsoft:
http://windows.microsoft.com/en-us/windows-vista/What-happened-to-the-Run-as-command
If you are logged on as a standard user, you can also use the Run as administrator command to run a program as another user, even if the user does not have an administrator account. To do this, click Run as administrator, and then select the user account. If you are logged on as an administrator, you will need to type runas.exe /user name in the Command Prompt window if you want to run a program as another user.
Related
I have VS2015 set up so that it always runs as administrator (a la something like this https://superuser.com/a/468056/48346).
Now I want to create an AHK script to launch Visual Studio and run a few UI / Keyboard commands to get it ready for me - I want this script to run at login but that's a later problem.
The Null solution is obviously to turn UAC off, but I don't want to do that.
So far I'm stuck on the way the UAC prompt always grabs the whole screen and I can't use AHK to click the "yes" button or send any keyboard commands to press enter or something like that. I guess this is the whole point of the UAC prompt, not to allow anything to do it for me.
Is there no way to open VS without the UAC prompt showing? I'd need to open a specific solution file, so if it's possible from the command line, the solution file would need to be included in the command so that it opens.
So far I've tried the AHK command RunAs, but I couldn't get that to work - my personal user is a domain user that's a member of the admin group on my local machine. I tried creating a specific runner account with admin privileges and use the RunAs command with that, but that didn't work. I get an access is denied when I run this AHK code:
RunAs, runner, password, LocalComputer-Name
Run, %comspec% /k "start c:\Users\myacc\Documents\path\solution.sln"
The runner account is in the Administrators group on my local machine, which has full access to the folder where the solution file is stored including the file itself - so I don't understand why access is denied.
Is this not possible?
Ps. I'd ask this question on the AHK forum, but registering there seems to not send any confirmation email at all (no, it's not in my spam folder), so I can't post it there.
The answer is to schedule a task that runs with the highest privileges to run the script at logon. The problem I was really having was to construct and debug the script - running a task each time was cumbersome. So to debug the script, just right-click the script and select "Run as administrator". Then the UAC prompt will pop up before the script starts running but not during the script. Then when the script is ready, just schedule a task to run at logon and check the "Run with highest privileges" option for the task. Then you can try the task by right-clicking the newly created task and selecting run, then you will see it run without the UAC prompt.
My final version of the script just opens the solution file using Run, no RunAs required - the scheduled task is set to run as my user, with the highest privileges.
Run, %comspec% /c "start c:\Users\myacc\path\solution.sln"
I'm having a mystery.
I have a Windows 7 PC, I am an administrator on it. But, I have a software tool that still requires me to run it with "Run as Administrator" to work properly. Why isn't it enough just to be the admin and just run it with double-click?
The thing gets complicated - I have another PC with a user that is an administrator also, and the tool runs there just with double-click properly.
What could be the difference between the PCs? In both of them, the user is an administrator!
Thanks for any help,
This is the impact of the User Account control (UAC), which assigned 2 tokens to admin accounts and runs the shell (explorer) and all started programs by default with the filtered token which represents standard user rights. To request admin rights, you have to right click and select “Run as administrator”.
I need to create an NSIS installer, which runs with administrator privileges. I request these privileges with
RequestExecutionLevel admin
So far this works. But I also need to place shortcut links on the users desktop. I do NOT want to create the shortcuts for all users but only for the currently logged in user. So I use
SetShellVarContext current
in the installer sections. If the current user has admin privileges, this works. If I have a normal user, Windows (7) asks for credentials for a privileged user, which is also correct. But the installer then creates the icons on the privileged users desktop, and not on current users.
So, how can I tell NSIS, that it should create desktop icons for the current user if she has no admin privileges?
FYI, if I omit both RequestExecutionLevel and SetShellVarContext, I am also prompted for administrative rights but the installer creates icons on the current user desktop as well as for the admin user. I think this is some kind of compatibility behavior.
You are not really supposed to do this (because of this exact issue) and you are basically asking how to create a installer that is broken by design. This is not a NSIS specific problem and not even UAC specific, it has existed since runas was added in Win2000! When you elevate with runas/UAC the new process is executed as that user and with their HKCU and shell folders...
If you need "RequestExecutionLevel admin" in your script then you are doing machine level things and should therefore call "SetShellVarContext all" and install the files in $ProgramFiles and write the uninstall registration under HKLM. This is true for any version of NT, not just Vista+/UAC. (Most people forget to test as non-admin on NT4 and NT5)
If creating shortcuts for all users is such a big problem then I suggest you enable the "Don't create shortcuts" checkbox on the startmenu page so the user can decide.
If you still want to force broken behavior then you need to use this plugin. (You should be able to find plenty of topics about this plugin on the NSIS forum)
Suppose I have a script that needs to read information from places that normal user is not permitted to read (e.g. other users' folders).
Currently all I can do is complain about not being run as a "superuser" and quit, but I would rather like the script to ask for elevation itself.
According to MSDN and PerlMonks, you can try:
Win32::FileOp::ShellExecute( runas => 'yourprogram.exe' )
or
Win32::FileOp::ShellExecute( runasuser => 'yourprogram.exe' )
These should (not tested) ask you for elevation when it is needed. (Works on Windows 7 only).
Related: Requesting Administrator privileges during runtime
If you're ok with launching through a shortcut, you can use the following:
Create a shortcut to perl.exe
Edit the shortcut.
On the Shortcut tab, change "Target" to
"c:...\bin\perl.exe" "c:...\script.pl"
[Optional] On the Shortcut tab, change "Start in" to the path of the directory in which your script resides.
On the Shortcut tab, click "Advanced", then check "Run as Administrator".
There's a tool called "runas", but I can't seem to get it to work without asking you for Administrator's password.
Tired of having no good answer to this question in my own work, I wrote Win32::RunAsAdmin. All it does is call the Windows Shell via OLE with "runas" as the verb, but it packages it conveniently so all you have to do is stick the following at the beginning of your code:
use Win32::RunAsAdmin qw(force);
During the import step, it will check for elevated privileges, and return silently if you're already running in elevated mode. Otherwise, it restarts the script in elevated mode with a UAC popup.
No matter how I open it, cmd.exe always opens with admin privileges. How can I open it without? Is there some registry setting missing? Even if I open it directly from the run dialog or by double clicking in the system32 folder it still opens with admin privs.
Thanks.
Found out I was missing a registry key. In HKEY_CLASSES_ROOT\Directory\shell\cmd I was missing the String Value "Extended". Added this back in and restarted the machine got rid of the defaulting to admin privileges.
EDIT: I had UAC turned off for my profile (to stop incessant "are you sure you want to open this .exe" warnings), and turning that back on has stopped cmd always running with greater privileges.
After some unclear actions (switch UAC on/off ?) I ended up in the same situation as described above:
Cmd.exe always starts in Adminstration mode.
Linking in VS failed with the message:
Project : error PRJ0003 : Error spawning 'C:\windows\system32\cmd.exe'.
The Properties | Compatibility tab is greyed out, so switching this off seems impossible (Compatibility modes cannot be set on this program because it is part of this version of Windows).
To recover from this situation you have to edit the registry to remove the RUNASADMIN preferences that is associated with cmd.exe.
The 'RUNASADMIN' preference is stored in these registry keys:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
Delete the values named c:\windows\system32\cmd.exe and you are back in business !
Kees
Right click on the cmd.exe, select properties and check the compatibility tab. Is the Run this program as an administrator checkbox checked?
This is only happening because you're logged in as a user with administrative privileges.
Since doing so defeats the entire Windows security model, you shouldn't be doing that in the first place. Create a standard user account and log in with that, instead. The command prompt should then not open with administrative privileges since you don't have administrative privileges.
If, as a standard user, you need to open a command prompt with administrative privileges, you'll need to right-click on the shortcut and select the "Run as Administrator" option (just look for the UAC shield). You'll need to provide sufficient credentials to authenticate yourself as an administrator, and then you'll have the authority to wreak whatever havoc you wish.
Found a way to run as a specific user even when UAC is turned off from http://www.sevenforums.com/general-discussion/235987-run-cmd-exe-given-user-administrator-command-line.html
This is the way to start cmd.exe as any user. Replace "username" with the correct one:
cmd.exe> runas /user:username "cmd.exe"
Right click on the cmd shortcut, navigate to properties, select advanced options and uncheck the 'Run as admin' option.
Check this video for better understanding - https://www.youtube.com/watch?v=3Mxh5TNSIl8&list=PLg8CURsOKswrzPs9fMhnmdy9TP7AkOOX1&index=1