I need using powershell script to kill a process, however access denied. How can I get admin with powershell script? In addition, I do not want to input Admin account and password manually. The Get-Admin process needs to be done automatically. What am I suppose to do?
You would need to elivate your script, or console prompt, to use the "run as administrator" option. A good example script can be found here on how you might do this in your script.
The meat of the script provided in the link just takes the user running the script and verify if the current session is elavated. If it is not you have to open one up as that in order to kill a process. You would also deal with UAC if you are on Windows, that if the user running it does not have local admin rights you will be prompted to enter credentials.
Snippet of the code that verifies if the execution account is admin:
# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
$myWindowsPrincipal.IsInRole($adminRole)
You can find a few other options to get elevated permissions here.
Just do
start-process pwsh -Verb RunAs
or
start-process powershell -Verb RunAs
to get yourself an elevated shell. Then run the command you want
Related
I'm one of the IT admins in our company. Lately, cyber-security want to get stricter on how easily users can read and/or write data on USB sticks and external mass storage. In addition all new users getting new Windows notebooks will only have "non admin" permissions. All requests to install software etc must come through the IT desk.
An Active Directory OU has been created and some test notebooks have been assigned to it. My boss would like to me to write and test some Powershell scripts that would allow my colleagues and I (in a screen-sharing session with the user) to temporarily delete the registry keys that control USB storage access (until the next group policy update comes along). The hard part has already been taken care of. The intention is that script will be stored as a Nal-Object on ZenWorks, so the user would not be able to see the source code (kinda similar to an exe file that is just double-clicked on).
The code that is causing hassle...
# self-elevate to admin user - code at the very top of the PS file..
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
Start-Process PowerShell -Verb RunAs "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
exit;}
# all the main code follows..
Here, if I run the script (in an non-admin account) I am prompted by UAC to enter the name and password of a local (or domain) admin account, a new window/session in PS opens and I can run whatever main commands need running.
The problem however is that is that when prompted for credentials and then type the correct password for a local non-admin account (as some users are inevitably going to do!) a new empty PS window/session just keeps opening indefinitely in a periodic fashion.
I've also tried adding an 'else clause' to the if-statement (to show an alert to the user and/or force quit Powershell, but it never seems to be get executed).
When I test this on a computer is that non part of any domain etc, I just get a "user is not authorised" kind of alert in UAC and no error gets the chance to propagate.
Is there any kind of workaround for this? It would be great too if the UAC prompt just defaulted to the name "ROOT\install". Nobody knows that password to this account except for IT admins.
I've also run Get-ExecutionPolicy -List... MachinePolicy and LocalMachine are "RemoteSigned", everything else is "Undefined".
I don't think execution policy plays a role in this strange loop, but I am open to being wrong. The script I am testing has not been through any signing procedures etc and is just sitting locally on the Desktop of one of the test computers.
Thanks.
Your symptom is mysterious; it implies the following:
The UAC prompt triggered by Start-Process -Verb RunAs mistakenly accepts a NON-admin user's credentials.
On re-entry into the script, the test for whether the session is elevated (!([Security.Principal.WindowsPrincipal] ...) then fails, and Start-Process -Verb RunAs is run again, at which point no UAC prompt is shown, because Start-Process does think the session is elevated and instantly spawns a new window.
The result is an infinite loop of new windows getting opened.
I have no idea what would cause this discrepancy - do tell us if you ever find out.
As workaround, you can try the following approach:
if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
$passThruArgs = "-NoProfile -ExecutionPolicy Bypass -NoExit -Command `"cd \`"$pwd\`"; & \`"$PSCommandPath\`""
if ([Environment]::CommandLine -match [regex]::Escape($passThruArgs)) {
throw "You entered non-admin credentials. Please try again with admin credentials."
}
Start-Process -Verb RunAs PowerShell $passThruArgs
exit
}
# all the main code follows..
'Now running elevated...'
That is, the on re-entry the process command line is examined for containing the same arguments that were passed on elevated re-invocation. If so, the implication is that even though the UAC prompt accepted the credentials, the new session still isn't elevated, and an error is thrown.
Note that I've added -NoExit to the re-invocation, so that the new window stays open, which allows the results to be examined.
I have a windows service that runs and manages multiple processes.
All the processes are running under the user account as per the task manager details tab. So one of the processes is executing a PowerShell script to do some operation that requires a local user account.
I tried logging $env:username, it says the PowerShell script is executed under the system account.
If I manually start the process without any help from the windows service then the PowerShell script executes successfully and also logs that the $env:username is locally logged in user account.
Note: the windows service is starting those processes using CreateProcessAsUser method which supposedly starts the child process under local user account. But somehow it seems that the task manager shows its running under user account but behind the scenes, it's running under the system account.
Can anyone tell me how I can execute the script under a local user account?
The cmd that I use to run the PowerShell script is
Powershell.exe -NoProfile -ExecutionPolicy Unrestricted -Command ../powershellscript.ps1
I use the following code to rerun a script with admin privilege if necessary.
# Require admin
if(!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs
exit
}
However, on some systems, when I right click the script and choose run with powershell, it will prompt me for something like yes, no, all, cancel... etc. I don't know exactly when this will happen. How can I force the execution policy change without the prompt aforementioned? I checked the document and it seems there is no -force parameter for powershell. There is a -force parameter for the cmdlet set-executionpolicy though.
The reason "why" sometimes get the prompt is because the account on some "systems" is already running it as Administrator(The elevation have already happened before at login or being disabled by GPO).
However, if you are running this on a remote machine, you will not need to elevate permissions if you already have admin rights to that machine, but running it from the current session would need the elevation unless the user is already signed as admin.
Check the documentation from Microsoft on How User Account Control works
https://learn.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works
On the other hand, I think there might be a better method for your usecase.
I am running powershell script through jenkins. It has one cmdlets which require elevated permission. so i am writing those cmdlet as below
start-process powershell.exe -verb runas -argumentlist "net localgroups administrators domain\user /add"
But this prompts a UAC where i have to manual click yes. then its moves further.
I want to elevate the cmdlet without giving UAC prompt and continue to go ahead....
The account used to run the script has admin permission on that machine.
Besides disabling UAC - which obviously should be the last resort - you may achieve your goal with creating a 'scheduled' task which is set up to run elevated and trigger that task from Jenkins.
The difficulty here will be probably about how to pass information to and retrieve information from the task - maybe you can achieve that via some files of well-known paths.
See here for how to set up such a task and here for how to trigger it.
As I do not have any Jenkins installation right now I could not test it though - sry.
The problem is the switich:
-verb runas
That instructs Windows that you need your code to run as an Administrator.
Remove that, and Windows will stop prompting the user for administrator privileges.
Your next question might be:
But i want a standard user to be able to do things that require administrative privileges.
Sorry, that is not allowed on secure operating systems.
if I'm a standard user
I simply can't just decide to be an administrator
I actually have to be granted those rights.
The 8 year old, or the corporate desktop user, can't just become an administrator because they wrote:
start-process explorer.exe -verb runas
They will need me, or someone from IT, to walk the 6 buildings over to type in my admin credentials - because i actually do have Administrator privileges.
Imagine Life Before UAC
Every developer complaining about UAC, who hates UAC, wants to go back to before UAC. Lets imagine that.
It's 2002, you're running Windows XP SP3
There's no UAC, so you're always a standard user
And you want to run some code as an Administrator.
You can't do that; you're a standard user.
The only solution is to:
Fast User Switch
and get an Administrator to login to the machine
have them run your script
they then logout
and you fast-user-switch back to your own account
UAC is much better; since they can just type their credentials into the UAC dialog:
But I Just Don't Want A UAC Prompt
You might be saying:
I don't care about any of that. I just don't want the UAC prompts. I want it to work like it did in Windows XP
If you don't want the UAC prompts, and you want it to behave like it did in Windows XP: then you absolutely can do that. You are perfectly free to turn off UAC.
Standard users will always be standard users, with no way to elevate
Administrators will always be administrative users, with no need to elevate
And that is your preference, and you can do that.
Many other users don't want to do their day-to-day work as an Administrator. But since you're only running your script on your computer: it's fine.
I would like to invoke Clearprojexp.exe as runas different user.
I was trying to use as follows in my powershell prompt
runas /noprofile /user:Domain\UserName Clearprojexp -credential (Powershellfile.ps1 -get "E:\EncryptedPwd.txt")
But it asks to enter password manually. As powershell has provision to store Password as encrypted string in file, is there any way i can pass the encrypted password from the file?
My intention is to just run a script to open Clearcase project explorer as runas different user.
There is a /Savecred option but i am not sure whether it would store the password in secure form.
You could try a powershell script equivalent of runas, like this one
like using runas.exe to elevate a process (like su in unix/linux) but runas /savecred and saving credentials can be “disabled” by policy. That’s why i use su.ps1 through su.bat instead of runas.exe. Several idea has been implemented from other posts. Thank you for their/your help:
PowerShell Script: Export-PSCredential and Import-PSCredential
Powershll scripts blog
$ScriptFilenam [-UserName:]UserName [[-FilePath:]program [arg1] ['arg 2'] [arg...]]
[-SaveCredential] [-RdpSaveCredential] [-DeleteCredential] [-Help]
Runas does not take a credential in the fashion you're attempting to pass it as. -credential is a powershell switch, it will not work with Runas. If you type Runas /? at the cmdline you will see down at the bottom that the first NOTE: says "Enter User's passsword only when prompted. This utility will prompt you to enter the password of the user.