I'm researching whether it's possible to host an always-running Powershell remoting process.
By default, PSRemoting will start a process as the authenticated user.
However, using custom PS Session Configurations, it's possible to set a "run as account" that will ensure that the remote process (on the server, so to speak) always runs as a "known" user, regardless of the identify of the connecting client.
The reason for me researching this, is that I notice that Ansible runs quite slowly against windows servers, and I suspect this is due to the fact that the remoting process on the server gets spun up with each command Ansible sends. I'd like to see if it's possible to have an always-running process that is "ready" in order to speed up executions.
This is as far as I've gotten:
$ansiblecred = get-credential
New-PSSessionConfigurationFile `
-path "C:\sessionconfig.pssc" -SessionType Default `
-RequiredGroups #{ And = 'Administrators' }
Unregister-PSSessionConfiguration -Name ansible -force
Register-PSSessionConfiguration `
-Path "C:\sessionconfig.pssc" -Name ansible `
-RunAsCredential $ansiblecred -AccessMode Remote `
-UseSharedProcess -ThreadOptions ReuseThread
restart-service winrm
$remotecred = Get-Credential
$i = 0
while ($i -lt 10)
{
#This is slow because the remoting session is setup/teard down every time
Invoke-Command -ComputerName "localhost" -Credential $remotecred -Authentication Basic -ScriptBlock {$env:computername} -ConfigurationName ansible
$i ++
}
Even tho I'm connecting to the session with a different credential, the actual process runs as the "service" credential, so that part's good.
However, it seems to be still spinning up and down the process on each execution.
Just for clarification: The client here is not regular Powershell, it's client which will interact directly with the wsman service over http. So while I appreciate all responses, suggestions based around client-side Powershell code (such as new-pssession, invoke-command etc) are not gonna help :-|
Any pointers would be appreciated here, I'm trying to get to a place where the remoting process simply lives regardless of sessions being executed or not. Is this possible?
Create a session outside and use it in the loop.
$Session = New-PSSession -ComputerName $Server -ConfigurationName MyConfiguration
While(1){
Invoke-Command -Session $Session -Credential $remotecred -Authentication Basic -ScriptBlock {'my code'}
sleep 10
}
Related
When running the below code, i can put anything in the block at the bottom - I'm trying to copy a folder across to run an exe from a local folder and perform an install of that exe during the remote session to remote machines. I am getting Access Denied Errors. I read, i cant use the Kerberos Delegation Cmdlets which are only for a forest level of 2012 and above. Current Site has Domain Functional Level 2008 R2. Is there another way to achieve copying the files across during each remote session to the computers specified in the text file?
Thanks in advance
########################################
$Cred = Get-Credential DOMAIN\USER
$Computers = Get-Content C:\tab.txt | Where-Object { $_ }
ForEach ($Computer in $Computers)
# {
# if (Test-Connection -ComputerName $Computer -BufferSize 16 -Count 1 `
-Quiet)
{
# Creates a new remote PowerShell Session and script block - enter
the code you want to execute remotely from this block
$Session = New-PSSession $computer -Credential $cred
Invoke-Command -Session $Session -ScriptBlock {
Copy-Item -Path "\\print-server\pcclient\win\*" -Destination
"c:\pcclient" -Force -Recurse -Verbose
# Start-Sleep -s 10
# Start-Process "\\Print-Server\PCClient\win\client-local-install.exe" -ArgumentList "/SILENT"
}
}
Remove-PSSession -Session $Session
# }
This is because you're on a remote machine, trying to access another network resource. When you connect to the remote machine in PowerShell, you're effectively connected/authenticated to that machine only, (unless you specify otherwise) it doesn't have access to your credentials to access the network share, so the connection to the network share is treated as unauthenticated, hence the failure.
This article https://blogs.technet.microsoft.com/heyscriptingguy/2012/11/14/enable-powershell-second-hop-functionality-with-credssp/ covers it well, essentially in you will need to run this locally (to allow your machine to pass credentials):
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
On the server run (to allow the server to accept these credentials):
Enable-WSManCredSSP -Role Server –Force
And update your New-PSSession command to:
$Session = New-PSSession $computer -Credential $cred -Authentication CredSSP
If you want, you can share your credentials with only specific machines, or subsets of a domain using *.yourdomain.lan or whatever, if you connect to multiple machines, then it's easier to use -DelegateComputer *.
Basically, i have PowerShell on both servers, is there a way to make a connection between both servers in such a way that when I run a command on PowerShell of Server A then it also runs on PowerShell of Server B.
I am new to PowerShell. Any help would be great.
You can use the New-PSSession-cmdlet in combination with the Invoke-Command-cmdlet
First of all create a remote session object:
$remoteSession = New-PSSession -ComputerName "YourComputerName" -Credential (Get-Credential)
Afterwards, you can use the $remoteSession object to execute commands on the remote via:
$servicesOnTheRemote = Invoke-Command -Session $remoteSession -Verbose -ScriptBlock { Get-Service * }
Invoke-Command runs Get-Service on the remote host, fetches the service state, serializes the data, and sends the data to the calling host. Based on that $servicesOnTheRemote includes the service state of the remote.
Also checkout this usefull cheatsheet.
Hope that helps.
I need to execute powershell script on remote computer with admin privilegies.
I have 2 scripts: client and server.
When i start client.ps1 i invoke command on server machine but get access error. I get no error if I use simple code in server.ps1 like write-host "hello".
server.ps1:
Get-service -ComputerName 'client'
client.ps1:
$ScriptBlockContent = {
d:\server.ps1
}
$remote=New-PSSession -ComputerName 'server'
Invoke-Command $remote -ScriptBlock $ScriptBlockContent
Your problem is authentication. You have to enable the server to use your credentials for that. You can do this by using CredSSP.
Enable this on your client:
Enable-WSManCredSSP -Role Client -DelegateComputer ServerNameHere
Enable it on your server:
Enable-WSManCredSSP -Role Server
Now add this to your Invoke-Command:
-Credential Domain\YourUsername -Authentication CredSSP
A remark on that: With CredSSP, its easy to steal your credentials, if you connect to a compromised system (same as RDP). Be sure that you do this on secure computers only.
Your client is trying to open D:\server.ps1 and getting access denied. Your script block doesn't even contain the neccesary code to cause powershell to process the contents of the server.ps1 anyway. You have it way to complicated.
You need to properly define a script block:
$scriptblock = { Get-service -ComputerName 'client' }
$remote=New-PSSession -ComputerName 'server'
Invoke-Command $remote -ScriptBlock $scriptblock
Running this command will connect to the machine called 'Server' and tell it to run Get-Service on 'Client' You don't need a client.ps1 and server.ps1 It can all be done from 1 script.
You also need to ensure winrm is running and configured on the server.
I'm running into some trouble with the Invoke-Command cmdlet. I am logged into my local machine with my domain identity, which has admin rights on $server. If I manually enter my credentials, then use Invoke-Command, I get the error:
Cannot open Service Control Manager on computer ''. This operation might require other privileges.
# Works
Get-Service -ComputerName $server-ErrorAction Ignore
# Doesn't work
$cred = Get-Credential
Invoke-Command -ComputerName localhost -ScriptBlock {param($serverIPAddress) Get-Service -ComputerName $server -ErrorAction Ignore} -Credential $cred -ArgumentList $server
Is there something special about the built-in credentials that makes this work?
This is the classic kerberos double-hop.
The special thing that's happening is that the local computer has your credentials. It can talk to a remote computer and prove it has the credentials, without ever sending them.
However if the remote computer needs to access something on a third computer (second hop), it cannot prove it has the credentials (because it doesn't), so it cannot authenticate.
This is Kerberos working as designed.
Using Invoke-Command to localhost is still doing a remoting connection, so it still counts as a hop. The Get-Service call is a second hop.
Consider:
Invoke-Command -ComputerName $server -ScriptBlock { Get-Service -ErrorAction Ignore } -Credential $cred
That will work (as long as powershell remoting is enabled on the remote machine).
Otherwise, you need to enable kerberos delegation, or CredSSP, or (best if possible) rework whatever you're doing to not require a double hop.
Be wary of CredSSP (and delegation in general).
I have a client and a server. The client will call a script like:
#Predefine necessary information
$Username = "Niels"
$Password = "password"
$ComputerName = "192.168.1.51"
$Script = {powershell c:/build/jclbuild2.bat}
#Create credential object
$SecurePassWord = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $Username, $SecurePassWord
#Create session object with this
$Session = New-PSSession -ComputerName $ComputerName -credential $Cred
#Invoke-Command
$Job = Invoke-Command -Session $Session -Scriptblock $Script
echo $Job
#Close Session
Remove-PSSession -Session $Session
On the server the jclbuild2.bat will run and access a network drive like \\otherserver\something, it says access denied if I do this command:
cmd.exe /C copy "\\server\file1.pdf" "\\server2\file1.pdf"
How do I access a network drive from a powershell file on a remote server? The user I use with the $username and $password should have access to the network drive.
I think it's a double hop issue, which I don't know how to solve.
You can't do this using the default authentication mechanism. You need to use an authentication mechanism that allows you to flow credentials, not just identity. Kerberos is one of these. CredSSP is another that is built into Windows starting from Vista/Server 2008 onwards.
I have experience setting up CredSSP. Note that there is some security risk because the target machine will have access to the credentials as plain text.
To set it up you will need to run two commands (both from an elevated shell). One on the machine you are running the above script on (the client) and another on the target that you will be connecting to via remoting (the server).
Enable-WSManCredSSP -Role Client -DelegateComputer $ComputerName -Force
This enables delegation to $ComputerName from the client (note you may have to use the FQDN). For security reasons you should avoid using the wild card '*' although you might consider using '*.mydomain.int' to enable delegation to all machines on the domain.
On the target server
Enable-WSManCredSSP -Role Server
Then when you create the session use the -Authentication flag
$Session = New-PSSession -ComputerName $ComputerName -credential $Cred -Authentication Credssp
There are questions on ServerFault on setting up CredSSP. There is also a blog post here with additional explanation. This post has troubleshooting tips for some commonly encountered error messages.
Another option is to use a delegated session on your server.
Basically, you create a custom remote session that uses the -RunAs parameter to designate the credentials that the session will run under. You can also constrain what scripts and cmdlets can be run in the session and specify who can connect to the session.
In this case, the session would run as the Niels account, and everything done in the session would be under that account authority, regardless of who was connected to the session. From that session, you can now make one hop to another server without needing CredSSP.
This also eliminates the security risk involved in storing that account password in the script file on the client computer.
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/03/use-delegated-administration-and-proxy-functions.aspx