I am playing around with setting up some scripts on a vpn on a client's network. This client generally assigns an ActiveDirectory account on their network and use it to manage permissions (eg. to databases). Ok, that makes sense.
But here is something that confuses me:
start-process runas.exe "/user:CLIENTDOMAIN\George.Mauer /netonly W:\tools\LINQPad4\LINQPad.exe
queries for a password and runs just fine (and I can access the database)
But
Start-Process W:\tools\LINQPad4\LINQPad.exe -Credential (Get-Credential)
and entering CLIENTDOMAIN\George.Mauer and my password at the popup prompt always results in an error
Start-Process : This command cannot be run due to the error: The user name or password is incorrect.
Are these not the same thing? What's the difference between runas and -Credential? And a secondary question - how do I Start-Job with my CLIENTDOMAIN\George.Mauer credential?
/netonly runs the process as the current user and only network connections are made with the other credentials.
Start-Process will run the process (and all its network connections) with the other credentials. There's no way to achieve the /NETONLY functionality with Start-Process.
You'd have to p/invoke the Win32 API to achieve /NETONLY functionality. If you're up for the exercise this is the API you'll need to use LOGON_NETCREDENTIALS_ONLY with:
http://www.pinvoke.net/default.aspx/advapi32/createprocesswithlogonw.html
More resources:
example code with LOGON_NETCREDENTIALS_ONLY
CreateProcessWithTokenW function
To run a job as a different user:
Start-Job -ScriptBlock {whoami} -Credential (get-credential) | Wait-Job | Receive-Job
Related
I'm trying to run invoke-command to launch a powershell script in a powershell file on a remote computer. I'm using the credentials for a user with Administrator privilege. The command needs to be executed by running powershell as an administrator. There are licensing issues with the application that i'm trying to invoke using the powershell script, so i cannot change the credentials to Administrator but need to run with that particular user itself. I have tried using -RunAsAdministrator at the end of the Invoke-Command, but i got an error saying:
Invoke-Command : Parameter set cannot be resolved using the specified named parameters.
$command = {
cd Folder
C:\Folder\build.ps1
}
Invoke-Command -ComputerName $RemoteSystemIP -ScriptBlock $command -credential $Credentials1 -ErrorAction Stop -AsJob
I'm trying to execute this as a background job that's why i added the -AsJob parameter.
Its been several days and i haven't found a solution yet.
tl;dr
The only way to get a remote PowerShell session to execute elevated (with admin privileges) is to connect with a user account (either implicitly or via -Credential) that has admin privileges on the target machine.
With such an account, the session automatically and invariably runs elevated.
The Invoke-Command's -RunAsAdministrator switch can only be used with (virtualization) containers (-ContainerId parameter), not regular remoting (-ComputerName parameter).
You cannot elevate on demand in a remote session (the way you can locally, interactively with Start-Process -Verb RunAs).[1]
Instead, you must make sure that the credentials you're passing to Invoke-Command -Credential to connect to the remote machine with refer to a user account that (also) has administrative privileges on the target machine, in which case the remote session automatically and invariably runs elevated (with admin privileges).[2]
If you cannot pass such credentials, I think you're out of luck.
To test if the current user has administrative privileges:
# Returns $true if elevated, otherwise $false.
[Security.Principal.WindowsPrincipal]::new(
[Security.Principal.WindowsIdentity]::GetCurrent()
).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
Separately, here's a simple test you can run from inside a session to determine whether it is running with elevation:
# Returns $true if elevated, otherwise $false.
[bool] (net session 2>$null)
[1] Unless the session at already is elevated, -Verb RunAs presents a pop-up UAC dialog that a user must confirm interactively, which is not supported in a remote session.
[2] The same applies if you use "loopback remoting", i.e. if you target the local machine via remoting, using Invoke-Command -ComputerName ., for instance, with additional restrictions, however: You cannot use a user that is authorized for remoting but isn't part of the local Administrators group, and if you use the current user (whether or not with explicit credentials), the calling session must itself be elevated.
I think you should do this:
$command = {
Start-Process "powershell" -Verb runas -Workingdirectory "C:\Folder\" -ArgumentList "build.ps1"
}
Invoke-Command -ComputerName $RemoteSystemIP -ScriptBlock $command -credential $Credentials1 -ErrorAction Stop -AsJob
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.
I've a strange problem that I can't understand. Maybe someone will be able to explain it to me.
I'm trying to automate the installation of an app for SharePoint in a multitenant environment. I run the scripts on a remote machine like this:
$session = New-PSSession -Name "Install App Session" -Authentication Credssp -Credential $InstallAccountCredentials -ComputerName $frontend
$installAppScriptPath = Join-Path $currentScriptPath "\SharePoint\InstallApp.ps1"
$job = Invoke-Command -Session $session -FilePath $installAppScriptPath -ArgumentList $customerUrl, $env:COMPUTERNAME -AsJob
Wait-Job $job
Inside the InstallApp.ps1 I invoke the Import-SPAppPackage command but I get an "Access denied.
You do not have permission to perform this action or access this resource." error. However, if I login to the machine with exactly the same credentials that are used as $InstallAccountCredentials and start the script, everything is working perfectly fine. The account that is used for running this script is an tenant admin account.
Is there something I miss in invoking the command?
PowerShell remote doesn't work for a significant portion of the SharePoint cmdlets. Use the client object model instead - you can invoke those methods from PowerShell as needed.
all,
I believe this scenario sounds indeed odd, but I do need your help on this.
First I use
Enter-PSSession -ComputerName myComputerName -Credential domain\user1
to remote to a third machine from my dev machine. I got a prompt like [myComputername]: PS C:\Users\user\. Then I try to Start-Process with another user, say domain\user2. However it failed, although the executable path fed to the Start-Process is full under control of domain\user2. I suppose there is no permission problem on this. For example
Start-Process -FilePath powershell -ArgumentList "-command" & {whoami} "" -Credential domain\user2 -WorkingDirectory workingdirectory
It wouldn't print the domain\user2. And it would if you run this command after remote desktop to the test machine. Anyone knows the root cause and the fix of this?
Thanks & Regards,
Jingfei
I believe you have the dreaded Powershell Remoting Second Hop blues.
http://technet.microsoft.com/en-us/magazine/jj853299.aspx
CredSSP:
http://msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx
Delegating credentials to a runspace:
http://www.vinithmenon.com/2012/11/delegated-administration-in-windows.html
I'm trying to execute the following script:
$Cred = Get-Credential
Invoke-Command -Computername Localhost -Cred $Cred -Scriptblock {Start "Notepad.exe" -Wait}
Well, the notepad comes up no problem as Administrator but it is not visible in the current user's account.
I think it's not possible to see gui in an interactive session with different credential, it live in another user session.
Workaround:
start-process notepad.exe -Credential $Cred
I've run into this problem with PS Remoting and could not find a way to get an app running under one set of credentials to show up on the interactive desktop of a different user. I eventually gave up and used SysInternals utility psexec along with its -i parameter.