I want to deploy code using powershell via Jenkins Job. This works fine in the powershell ise.
$username = "mydomain\builder"
$password = "notmypassword"
$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList #($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
$Arguments = "-ExecutionPolicy Bypass -File C:\Test.ps1 -NoNewWindow -WorkingDirectory C:\Windows\System32\WindowsPowerShell\v1.0 -NoLogo -NonInteractive"
Start-Process "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Credential $credentials -ArgumentList $Arguments
But when I run it from Jenkins which use the local system I get the following error message.
Start-Process : This command cannot be run due to the error: Access is denied.
At C:\WINDOWS\TEMP\hudson5557889306949142167.ps1:7 char:1
+ Start-Process powershell.exe -Credential $credentials -ArgumentList $
If change I change the Jenkins service to another account it works. Why won't elevated permission work under the local system account?
note: the only code in test.ps1 is New-Item c:\scripts\new_file.txt
There seems to be a restriction on certain commands when a script is run under LocalSystem. This makes sense in terms of security, given that LocalSystem:
has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system.
Reference: MSDN, The LocalSystem Account
There is a similar question at SuperUser: Can not create process with elevated permissions from LocalSystem account with no answer so far a reference to this answer now.
There is a similar question at TechNet: Runing PowerShell script with the permissions of the LocalSystem user with answers suggesting to run the script via Task Scheduler.
I can think of using runas with /savecred and a /user:... with appropriate permissions whose password never expires. AFAIR you have to invoke runas with /savecred interactively once, enter the credentials and it will take the saved credentials from the next invocation onwards.
Related
I want to run one command with saved credentials on powershell, i have the following script
$user = "test"
$passwd = ConvertTo-SecureString -String "ExtremelyStrongPassword" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $passwd
Copy-Item -Path "C:\Temp\*" "C:\Program Files\Test\" -Credentials $cred
The user doesn't have administrator permissions, but in the localhost we have an user with administrator permissions to run these process.
The error returned is "Access Denied"
How do i pass these parameters to run a command with elevation?
Never pass plain text credentials in a script. Use the Get-Credential cmdlet to collect and use them. Even doing this, the user will get prompted for a password.
This is what the -RunAs switch of Start-Process is for
Or set your script to auto elevate
Or use the credential switch of a cmdlet
Or use a scheduled task with whatever creds you need, and let the user run it.
Use the Requires statement at the top of your script
Store the need creds in the Windows Credential Store and call them
from there
about_Requires - PowerShell | Microsoft Docs
Short description Prevents a script from running without the required
elements.
#Requires -RunAsAdministrator
Start-Process
Example 5: Start PowerShell as an administrator This example starts
PowerShell by using the Run as administrator option.
Start-Process -FilePath "powershell" -Verb RunAs
Using what you have this way:
Copy-Item -Path 'C:\Temp\*' 'C:\Program Files\Test\' -Credentials (Get-Credential -Credential 'Domain\UserName')
With exception of the scheduled task approach, each will prompt the user for a password, which sounds like what you wanting to avoid. So, consider the following:
Accessing Windows Credentials Manager from PowerShell
This simple PowerShell class can be used for working with Credentials
Manager and Password Vault in Windows: checking if account information
is present in the vault, saving credentials to the vault and reading
stored login and password information from the vault.
https://gallery.technet.microsoft.com/scriptcenter/Accessing-Windows-7210ae91
Using the registry to store credentials:
Save Encrypted Passwords to Registry for PowerShell
I am trying to run a powershell script from another powershell script passing in the credentials of a different user and then using the credentials:
Start-Process powershell.exe -Credential "LON\my-user" -NoNewWindow -ArgumentList "-file C:\DevopsScripts\stuckApps.ps1"
I have this is numerous different ways all get the same error. I have tried setting the username and password before the command:
$username = "LON\my-user"
$password = "pass"
$PSS = ConvertTo-SecureString $password -AsPlainText -Force
$cred = new-object system.management.automation.PSCredential $username,$PSS
$env:USERNAME
Start-Process powershell.exe -Credential $cred -NoNewWindow -ArgumentList "-file C:\DevopsScripts\stuckApps.ps1"
But everything I try gets the error:
Start-Process : This command cannot be run due to the error: The user name or password is incorrect.
I know the username and password are correct as they have been tested on the cmd which it works fine:
C:\Users\ADM-me>runas /noprofile /user:LON\my-user"powershell.exe C:\DevopsScripts\stuckApps.ps1"
What am I doing wrong here and how could I fix this, preferably by setting the password beforehand, so this can be automated. Also this does not need to be done using Start-Process, just this is the closest thing I could find to working.
I think the problem I am having is this, in stuck apps it has this:
$conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString = "Server = mssql.co.uk; Database = mydata; Integrated Security = true;"
$conn.Open()
I need this to run the credentials that I am trying to pass through it or else I get this error.
`Exception calling "Open" with "0" argument(s): "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."
But I can't pass the credentials through as the only ones that work are admin ones, (which I have but then that will throw the error above). Is it possible for me to use the admin logins to access stuck apps then use the logins needed to connect on stuck apps as an AD login.
Your first attempt with -Credential "LON\my-user" can't work, but your second attempt is correct, building the object of class PSCredential, as required (see the type in Get-Help Start-Process -Parameter Credential, it is PSCredential and not String). I tried the same with some reused code here, and it works here both or CMD and PS1 calling a PS1 test script via Powershell.exe, using a local test account (sorry, no domain #home).
So even though my code ist not identical and the domain of the user is the local machine, the approach is the same compared to yours and - sorry that this does not solve your problem - I don't see that you are doing sth. wrong.
To play safe, please make sure though to test with the same Powershell version, the below scripts executed under W10 1607 (so Powershell 5.1.14393.1198), all scripts in the same directory.
testscript.ps1
write-host "Testscript is run with user: $($env:USERNAME)"
Start-Sleep 2
testrun.cmd
runas /noprofile /user:%COMPUTERNAME%\myaccount "powershell.exe -NoProfile -ExecutionPolicy ByPass -file %~dp0testscript.ps1"
testrun.ps1
$Username = "$($env:COMPUTERNAME)\myaccount"
$Password = 'mypassword'
$SecurePassword = ConvertTo-SecureString -String $Password -AsPlainText -Force
$ScriptFile = Join-Path -Path $PSScriptRoot -ChildPath 'testscript.ps1'
$Credential = New-Object System.Management.Automation.PSCredential( $Username, $SecurePassword)
$StartOpts = #{ 'FilePath' = 'powershell.exe'
'Credential' = $Credential
'NoNewWindow' = $false
'ArgumentList' = #( '-f', $ScriptFile,
'-ExecutionPolicy', 'Bypass',
'-NoProfile'
)
}
Start-Process #StartOpts
Some remarks on testrun.ps1
Don't mind the parameters for Start-Process being passed as a hashtable, it's just better readable for me, otherwise it makes not difference
The ArgumentList is being passed as a string array here - I prefer it this way so that it is automatically taken care for double qouting parameters, e.g. when the pathname of the script directory would contain spaces
The parameter -NoNewWindow passed to Start-Process seems not to have any effect here - a new window is opened
I always recommend to add the parameters -Noprofile and -ExecutionPolicy Bypass when using Powershell.exe to launch scripts or execute commands, just to make sure it works despite of the Execution Policy set or any present user or machine profile scripts.
However, at least the parameter -NoProfile seems not to work the same when Powershell.exe is being called fom the above CMD or PS1. Called from PS1, my machine profile gets nevertheless executed, but not fom CMD... interesting! The MSDN: PowerShell.exe Command-Line Help just says about this parameter: "Does not load the Windows PowerShell profile." Funny! There are six of them, see Technet: Understanding the Six PowerShell Profiles. I use "Current User, Current Host – console" and "All Users, Current Host – console". Lesson learned, but I am not sure if it's a bug or a feature.
I have been trying to run a script from a Windows Jenkins (slave) server. The script is written in PowerShell and requires elevated privileges (such as if one right-clicked on PS and selected run-as-administrator).
Jenkins launches its scripts the following way:
powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Users\JOHAN.DER\AppData\Local\Temp\2\hudson9084956499652818911.ps1'"
My script fails because it requires elevated privileges. How can I spawn a new elevated-privileged PS process (that does not require clicking because Jenkins can't do that) that could run my script?
Cheers!
The snippet below checks if current process is elevated and if not, it spawns a new, privileged process. It is little tricky to get output of the child powershell process, so I'm using transcript command to capture it. Below you can find my pipeline definition step:
powershell """
cd "${env.WORKSPACE}"
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
echo "* Respawning PowerShell child process with elevated privileges"
\$pinfo = New-Object System.Diagnostics.ProcessStartInfo
\$pinfo.FileName = "powershell"
\$pinfo.Arguments = "& '" + \$myinvocation.mycommand.definition + "'"
\$pinfo.Verb = "RunAs"
\$pinfo.RedirectStandardError = \$false
\$pinfo.RedirectStandardOutput = \$false
\$pinfo.UseShellExecute = \$true
\$p = New-Object System.Diagnostics.Process
\$p.StartInfo = \$pinfo
\$p.Start() | Out-Null
\$p.WaitForExit()
echo "* Child process finished"
type "C:/jenkins/transcript-${env.JOB_NAME}-${env.BUILD_NUMBER}.txt"
Remove-Item "C:/jenkins/transcript-${env.JOB_NAME}-${env.BUILD_NUMBER}.txt"
Exit \$p.ExitCode
} Else {
echo "Child process starting with admin privileges"
Start-Transcript -Path "C:/jenkins/transcript-${env.JOB_NAME}-${env.BUILD_NUMBER}.txt"
}
# put rest of your script here, it will get executed
# with elevated privileges.
"""
Even though this is an old thread, I still provide my methods here since I had the same problem, hoping to help anyone who is finding the answer.
First of all, This problem is not relevant to Jenkins, it's Windows's issue, you have to enable build-in Administrator to get an elevated privilege, here is the reference:
Administrator user
It is an unelevated administrator account
that is created by default during the installation of Windows. If an
administrator user tries to do something that requires elevated rights
(ex: run as administrator), Windows will display a UAC prompt for the
administrator user to approve before allowing the action.
Built-in "Administrator"
The hidden built-in elevated
"Administrator account" is a local account that has full
unrestricted access rights to the PC. By default, this "Administrator"
account will not be prompted by UAC.
After enabling build-in Administrator, you have two ways to elevate PS script which is triggered by Jenkins:
1.Login Windows with build-in Administrator:
This is the easiest way to achieve your goal, just log in with build-in Administrator, and everything are elevated, including the PS script triggered by Jenkins. (I am using this method.)
2.Pass credential and run as Administrator:
Add some codes in your PS script
$user = "Administrator"
$passwd = "password"
$securePasswd = ConvertTo-SecureString $passwd -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential $user, $securePasswd
#Use Credential to prevent from being prompted for password
#Use argument -Verb RunAs to get script elevated
Start-Process powershell.exe -Credential $credential -ArgumentList "Start-Process powershell.exe -Verb RunAs -ArgumentList '-File hudson.ps1' -Wait"
Try this :
powershell -Command "Start-Process powershell \"-ExecutionPolicy Bypass -NoExit -Command `\"cd \`\"%scriptFolderPath%`\"; & \`\".\%powershellScriptFileName%\`\"`\"\" -Verb RunAs"
How would I go about running an EXE as a different user? How could I prompt for credentials or atleast ask for the password for a local admin to launch an exe through powershell. I'm having a hard time getting the runas command to work.
This was the latest thing I tried:
runas -credential .\me c:\windows\system32\notepad.exe
This works in the powershell terminal:
runas /user:asdf c:\windows\system32\notepad.exe but doesn't ask for credentials in a standalone powershell script.
This is a simple operation.
Start-Process "c:\windows\system32\notepad.exe" -Credential $(Get-Credential)
Using Get-Credential will prompt the user for credentials, You can also store it in a variable.
$Creds = Get-Credential
Start-Process "c:\windows\system32\notepad.exe" -Credential $Creds
Try following
Start-Process notepad.exe -Verb RunAsUser
change directory to .exe directory and run below command
runas /netonly /user:<domain\username> .\<app name>
I have a script that runs as SYSTEM, if i try to start-process notepad.exe it's working fine. if i add -credentials $cred it shows Access Denied. The credentials i pass over has local admin access, so why is there Access Denied? with procmon on powershell.exe i can not identify any access denied operation, i can see that powershell access notepad.exe with success result.
any ideas?
in one forum-post I read that it's not possible to execute a command with -credentials as SYSTEM. is that so?
if so, is there any workaround?
to my background, i use a software distribution where any installation runs as SYSTEM, from there i want to execute a powershell script as different user.
i found a solution:
$secpasswd = ConvertTo-SecureString 'password' -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential ('domain\user', $secpasswd)
Invoke-Command -ScriptBlock { Start-Process powershell c:\temp\mmc.ps1 -verb runas -wait} -ComputerName localhost -Credential $mycreds -Verbose
its not exactly what i want because here you need to enable psremoting first. but its like a workaround.
any idea how this is possible without invoke-command would be appreciated