It works well if PowerShell open as administrator and command ran onto it to sign file.
Tried several approach to signed file with non-admin but unfortunately not success. It returned as 'file not signed exception' everytime.
Is there any workaround to perform file signing without admin user privilege. Is it must to have admin permission in order to perform same activity?
Unsure if this will work for your scenario but I found this a while ago which will check is PS is running as an Administrator. If it is not, it will restart as an Administrator at which point this would be skipped over.
I wish I could explain how it works. I have never dug into how or why it works.
If (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
$Arguments = "& '" + $MyInvocation.MyCommand.Definition + "'"
Start-Process Powershell -Verb RunAs -ArgumentList $Arguments
Break
}
Thank you for response but issue was in IIS user account. It did not appropriate permission to execute powershell. As we have set it to local system it start working.
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 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 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
How can I run a powershell with -command parameters?
I tried adding '-Verb runAs', but I get a null valued expression.
powershell -Verb runAs -command "(Get-Date (Get-Process explorer).StartTime).ToString('yyyyMMdd')"
I open a powershell with admin right, the command
(Get-Date (Get-Process explorer).StartTime).ToString('yyyyMMdd')
return a right value. But when I start a powershell without admin right, I get a null value.
So I think the problem is the 'powershell -Verb runAs' does not run the command in admin mode.
Note: I logged in as ad administer when I tried this.
So elevating PowerShell's process can be done from within a script if you don't mind running a script instead of just executing a command. This will check if the process is already elevated, and if not it will re-launch the process with the RunAs verb so that it's running with elevated rights.
# Elevate UAC if not already running As Administrator
# 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
# Check to see if we are currently running "as Administrator"
if (!$myWindowsPrincipal.IsInRole($adminRole))
{
# We are not running "as Administrator" - so relaunch as administrator
# Create an encoded string to re-launch the script bypassing execution policy
$Code = ". '$($myInvocation.MyCommand.Definition)'"
$Encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($code))
# Indicate that the process should be elevated
Start-Process PowerShell.exe -Verb RunAs -ArgumentList "-EncodedCommand",$Encoded
# Exit from the current, unelevated, process
exit
}
# End UACElevation
The code is a little convoluted with the encrypting of the command and what not, but I found that I sometimes had issues with execution policy blocking me if I didn't do it this way. This avoids execution policy blocking PowerShell from running scripts, since it technically isn't running a script, just an encoded command. That command just happens to be for it to run a script once the PSSession is started.
I would like an easy way to run a process with different privileges from the same user without asking or knowing his/her password. A dialog is okay if necessary. I would prefer not to launch a PowerShell sub-process to accomplish this.
Scenario 1:
PowerShell script is running in admin-mode. I want to launch a script or an .exe without admin privileges but on the same user.
Scenario 2:
PowerShell script is running in normal mode. I want to launch a script or an .exe with admin privileges on the same user.
Let's split this into three parts.
First determine if current session is running with admin privileges:
$CurrentID = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$CurrentPrincipal = new-object System.Security.Principal.WindowsPrincipal($CurrentID)
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator
# Check to see if session is currently with admin privileges
if ($CurrentPrincipal.IsInRole($adminRole)) {
write-host "Yes we are running elevated."
}else{
write-host "No this is a normal user session."
}
Now, if we are running with or without elevation, you can start a new process with elevated privileges like this:
$newProc = new-object System.Diagnostics.ProcessStartInfo "PowerShell"
# Specify what to run
$newProc.Arguments = "powershell.exe"
# If you set this, process will be elevated
$newProc.Verb = "runas"
[System.Diagnostics.Process]::Start($newProc)
And lastly, if we have elevated privileges, but would like to start a new process without...
I have no idea. Will have to try to find the answer to this, but as it is not a common scenario, I had no luck so far.
EDIT: I have now seen a couple of “solutions” for this scenario. There is no native way to do this in .NET/PowerShell. Some are quite complicated (Calls to some 12 COM objects). This vista-7-uac-how-to-lower-process-privileges is a good reference.
The one that seems most elegant to me, is exploiting a “bug” in explorer.exe.
Just launch you .exe using explorer.exe and the resulting process runs without privilege elevation again.
$newProc = new-object System.Diagnostics.ProcessStartInfo "PowerShell"
# Specify what to run, you need the full path after explorer.exe
$newProc.Arguments = "explorer.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
[System.Diagnostics.Process]::Start($newProc)
EDIT #2: Another way I have just found to start a new non-elevated process from an already elevated environment is to use the runas.exe with the 0x20000 (Basic User) trust level:
C:\> runas /showtrustlevels
The following trust levels are available on your system:
0x20000 (Basic User)
C:\> runas /trustlevel:0x20000 devenv
I use this as first command in all scripts that requires elevated mode, it transfer the script to another elevated process if I forgot to start up as Admin. You have to confirm so it's not suitable for automated tasks
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
$arguments = "& '" + $myinvocation.mycommand.definition + "'"
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break }