Has anybody gotten powershell remoting to work against CNAMES or host files.
a way to test, create a PSsession against localhost to make sure its working fine... then have a host record to 127.0.0.1 called something, then try to create a pssession against that.
I get this sort of error
[funkymonkey] Connecting to remote server failed with the following error message : WinRM cannot pr
ocess the request. The following error occured while using Kerberos authentication: The network pat
h was not found.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two d
omains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configu
ration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. F
or more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PS
RemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
If NTLM isn't working, I think you're getting hit by the loopback check stuff added in winsrv 2003 sp1+. You can add the CNAMEs to a special registry key that will include them in the exception list (which already includes localhost.)
ps> new-itemproperty hklm:\system\currentcontrolset\control\Lsa\MSV1_0
BackConnectionHostNames `
-propertyType multistring -val "cname1","cname1.local"
Some people just turn it off entirely (the loopback check) by setting a dword DisableLoopbackCheck (google it) but you really should control it tighter with the former method instead of taking the lazy route.
IIRC, this security feature prevents a particular type of credential theft called a "reflection attack." I don't remember the methodology but i'm sure you could find it online.
Related
I have two machines in my corporate network. All web traffic goes throught our corporate proxy which requires authentication with login and password.
Both machines are behind the company's firewall and proxy.
In machine 1, I have the following snippet in the Powershell profile.ps1 file:
$proxyString = "http://our.proxy.corp:8080"
$proxyUri = new-object System.Uri($proxyString)
[System.Net.WebRequest]::DefaultWebProxy = new-object System.Net.WebProxy ($proxyUri, $true)
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
The previous snippet ensures that proxy configuration is set up for multiple commandlets including Invoke-WebRequest
When Invoke-WebRequest is called from a local powershell session in Machine 1 the web request is executed normally:
C:\ > Invoke-WebRequest https://www.youtube.com
StatusCode : 200
StatusDescription : OK
When I execute the same command from machine 2 remotely on Machine 1 I get the following error:
Invoke-Command -ScriptBlock { Invoke-WebRequest http://www.youtube.com } -ComputerName Machine 1
Access Denied (authentication_failed)
Your credentials could not be authenticated: "General authentication failure due to bad user ID or authentication
token.". You will not be permitted access until your credentials can be verified.
This is typically caused by an incorrect username and/or password, but could also be caused by network problems.
For assistance, contact your network support team.
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
+ PSComputerName : Machine 1
It seems that the proxy configuration is not loaded when commands are invoked remotely on Machine 1.
I tried:
Explicitly sourcing the profile file when invoking remotely
Using the -Proxy and -ProxyCredentials options
Specifying the credentials directly in the proxy url "http://user:password#our.proxy.corp:8080"
But I keep getting the same error.
What am I missing?
Pretty sure this is occurring because of the Kerberos, double-hop problem. Given your description of execution: 'When I execute the same command from machine 2 remotely on Machine 1...'
And this from the CredentialCache page:
The DefaultCredentials property applies only to NTLM, negotiate, and
Kerberos-based authentication.
So in a nutshell, your Kerberos token containing all of your security information cannot be passed to a second machine* because of how Kerberos works--the remote machine never receives an actual token in memory for the remotely connected user so there's nothing to work with on the remote machine to pass forward again. In this case, to the proxy server.
CAVEATS:
PowerShell offers a way around this (CredSSP) but is a terribly insecure technology that opens security holes in your environment for password theft, lateral movement, etc.--I wouldn't recommend it.
Sources:
https://learn.microsoft.com/en-us/dotnet/api/system.net.credentialcache.defaultcredentials?view=netframework-4.8
This is too long for a simple comment, but to add to thepip3r helpful answer, this double-hop thing not a PowerShell issue, but a Windows proper limitation.
However, there are several articles on this double hop auth issue, that have been around for a while now, dealing with us folks when using PowerShell. Directly from Microsoft, Microsoft field staff and former staff, as well as others. Here are just a few that you'd find with a quick web search, 'PowerShell double hop', for your consideration (and t0 have a talking point with your management and team members) if CredSSP gets pushback, and from the times I've had to address this, it will.
Making the second hop in PowerShell Remoting
PowerShell Remoting and Kerberos Double Hop: Old Problem – New Secure
Solution
...helper functions for working with resource-based Kerberos
constrained delegation (RB KCD) and PowerShell remoting:
Enable-RBKCD, Disable-RBKCD, Get-RBKCD.
Get the files and slides on my GitHub here.
RB KCD works with a limited set of commands and functions running
under SYSTEM account in the kernel context.
RB KCD does not support WinRM / PowerShell remoting, because that runs
under the NETWORK account.
Enable PowerShell Double-Hop Remoting
How to avoid the double-hop problem with PowerShell
Resolve Double-Hop Issue in PowerShell Remoting
I am running a Minecraft server from my laptop since it has an i7 and more RAM than my desktop. I want to be able to see the server command line on my desktop and be able to enter commands while the server is actually running on my laptop. I was able to see the command line by setting up for remote access and running the command
Invoke-Command -ComputerName 10.0.0.53 -Credential Admin -ScriptBlock { & "RUNSERVER.bat"}
This made it so I am able to see what the server is outputting to the PowerShell window on my desktop and the server is running on the laptop like it should be, but I am still unable to enter any commands. I'm pretty inexperienced with PowerShell so I'm not too sure where to go from here. Anyone out there know how I can edit this so that I can input commands from the PowerShell window on my desktop?
[localhost] Connecting to remote server localhost failed with the following error message : WinRM cannot process the request. The following error with
errorcode 0x8009030d occurred while using Negotiate authentication: A specified logon session does not exist. It may already have been terminated.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting
Help topic.
+ CategoryInfo : OpenError: (localhost:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : 1312,PSSessionStateBroken
[localhost] Connecting to remote server localhost failed with the following error message : The WinRM client cannot process the request. CredSSP authentication
is currently disabled in the client configuration. Change the client configuration and try the request again. CredSSP authentication must also be enabled in
the server configuration. Also, Group Policy must be edited to allow credential delegation to the target computer. Use gpedit.msc and look at the following
policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is
enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of
the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (localhost:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : -2144108126,PSSessionStateBroken
2019-04-19 20:00:08,630 main WARN Unable to instantiate org.fusesource.jansi.WindowsAnsiOutputStream
2019-04-19 20:00:08,631 main WARN Unable to instantiate org.fusesource.jansi.WindowsAnsiOutputStream
Enter-PSSession -Computername "Laptop"
You are now in a remote powershell session on the machine you identified via the computer name parameter.
Some things to be aware of. If you're doing this in a workgroup and not a domain you're going to need to contend with passing credentials. You have to pass them as a credentials object in PS. So it looks a bit more like this:
$Creds = Get-Credential
enter-pssession -ComputerName 10.0.0.53 -Credential $Creds
for credentials enter a username and PW that exists on the remote machine.
The Firewall on the remote host also needs to be configured to allow inbound Windows Remote Management Framework traffic from your local host.
EDITED THE ORIGINAL ANSWER TO REFLECT MY LATEST ANSWER:
This is where Windows will fall short on these kind of things. Windows by default does not have Pseudoterminal (PTY) support.
Traditionally, in *NIX type systems, you can run ssh -t option to access screen mode (forces TTY).
You might have better luck using this powershell module and following their instructions here: https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH
I've made a app in C# that remotly updates the hosts file of the computers on our domain using powershell remoting. It works great but entry level IT Support position in our company do not have their domain accounts part of the admin group on our workstations. They can however use a local admin account. I'm trying to add a 'Connect using a different account' feature but quickly ran into some hurdles. I've fixed all of them but one:
I cannot get it to authenticate using a remote local account and all of my Googling hasn't yielded any solutions.
Here's the code I'm using to update the hosts file:
psInstance.AddScript("Invoke-Command -ComputerName " + computerName + " -ScriptBlock { \"" +
hostsTextBox.Text.Replace("\"", "`\"") + "\" | Out-File c:\\windows\\system32\\drivers\\etc\\hosts }" +
(differentCredentialsCheckbox.Checked ? "-Credential \"" + computerName + "\\\" -Authentication Negotiate " : ""));
When using different credentials, it fails with the following message:
[COMPUTERNAME] Connecting to remote server COMPUTERNAME failed with the following
error message : WinRM cannot process the request. The following error with error code
0x8009030e occurred while using Negotiate authentication: A specified logon session
does not exist. It may already have been terminated. This can occur if the provided
credentials are not valid on the target server, or if the server identity could not
be verified. If you trust the server identity, add the server name to the
TrustedHosts list, and then retry the request. Use winrm.cmd to view or edit the
TrustedHosts list. Note that computers in the TrustedHosts list might not be
authenticated. For more information about how to edit the TrustedHosts list, run the
following command: winrm help config. For more information, see the
about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (COMPUTERNAME:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : 1312,PSSessionStateBroken
Now if I understand correctly using a remote local account only works if:
The connection is made using HTTPS however that brings it own set of problems. A certificate would need to be created for each computer the tool is meant to be used and install on our 500+ workstations. Also, the process need to be started over if the technician gets a new computer (which shouldn't happen often but has a non-zero possibility)
The computers trusts each other using TrustedHosts but that too has the same problems as #1.
Note: We are the local IT group working at one of the branch of a multinational company, we do not have access to GPO so we do not have any easy ways of pushing certificates to our workstations. Also, each groups within our branch are secluded on their own VLAN.
Does anyone can think of a way to achieve what I'm trying to do?
Actually it's not that hard.
I think you read the manual wrong ;-) I can make a similar case work just fine by adding the remote server to the trusted hosts on the client server (the one initiating the session).
You need EITHER https or trusted host. Not both.
To update trusted hosts (overwrites whatever might be in there):
winrm s winrm/config/client '#{TrustedHosts="ServerName"}' so you might want to do some string manipulation to add to any existing hosts.
If you get an error in that command, ensure a winrm quickconfig first.
My invovation is simply:
Invoke-Command -ComputerName $rmServerName -Credential $rmCred -ScriptBlock $block -ArgumentList $destName -ErrorAction:Stop
This works for me across domains with no SSL setup.
You're correct about needing HTTPS and TrustedHosts. One thing you might not be aware of is that the computers probably already have certificates. If there is an enterprise CA set up in the domain, the computers are probably set up for autoenrollment.
Constrained Endpoints
Something else that may work is to create a special Powershell endpoint for this task, and give it a RunAsCredential of the local user. I am not 100% on whether it works with a local user but I think it could.
If you're not familiar, the steps are to use New-PSSessionConfigurationFile to create the session definition, then use RegisterPSSessionConfiguration with that file to register it on the local machine. In the latter call, you can supply a -RunAsCredential and the powershell session will run under those credentials. You can delegate access to non-administrative (domain) users to access this endpoint (use the -ShowSecurityDescriptorUI parameter of Register-PSSSessionConfiguration to make this easy).
This won't require HTTPS nor TrustedHosts.
I have done this before and it definitely works, I just don't know for sure if you can use a local admin for the RunAs user.
If not, you can use a domain account with local admin rights; the helpdesk people won't be authenticating directly as that user so they won't need its credentials.
References
New-PSSessionConfigurationFile
Register-PSSessionConfiguration
We use custom credentials for one of our tools and rather than using custom credentials in PowerShell we launch a new process using NetOnly credentials.
We do this in C# however you can also just run the application using the runas /netonly /user:localadmin and you're prompted for a password.
I am trying to take backup of my server from client machine using powershell.
i am trying to execute a batch file which is on my server, but i am not able to make connection with my server. I searched a lot and tried
Test-WSMan : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or i
f the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be a
dded to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the Tru
stedHosts list might not be authenticated. You can get more information about that by running the following command: wi
nrm help config.
At line:1 char:11
+ Test-WsMan <<<< 182.50.121.100 -credential $cred -authentication default
+ CategoryInfo : InvalidOperation: (182.50.121.100:String) [Test-WSMan], InvalidOperationException
+ FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.TestWSManCommand
can any one tell me how can i execute the bat file step by step
Have you added your host name or IP in "GPEDIT" i.e.Group Policy and enabled to use fresh credentials?
Please follow the step if you might have missed something.
(http://www.ifunky.net/Blog/post/How-To-Enable-PowerShell-Remoting-(WinRM).aspx ,
http://blog.crayon.no/blogs/janegil/archive/2010/03/04/enable_2D00_and_2D00_configure_2D00_windows_2D00_powershell_2D00_remoting_2D00_using_2D00_group_2D00_policy.aspx)
They have enough information to get started. Sometimes if everything is enabled its a best idea to restart remote management services.
This following is not working for me -
%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Noninteractive -command "& Invoke-Command -ComputerName "Spider_LT_86" -ScriptBlock { msiexec.exe /i "D:\3PDInstallers\ETLBackgroundWorkerSetup.msi" /qn /l*vx "D:\3PDInstallers\logs" }"
all I need to do is run msiexec on a remote machine. I am assuming that the user running the script will have required access to the remote machine.
The script doesn't work even when the Computername points to the local computer (and running msiexec with the same logged in user works fine, so it doesn't look like a permissions issue) - I have ensured that the WinRM service is running, and I also disabled to firewall to check whether that is the cause of issue, but no luck so far. What am I missing here?
This is the full error but it pretty much lists all possibilities -
Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using
Kerberos authentication: The network path was not found.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting He
lp topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
UPDATE:
When I use -Credentials with just the username, it pops up a login window to get my password and then on entering it, gives the following error - the user does have admin access so I don't know what's wrong.
The
[spider_lt_86] Connecting to remote server failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
This is more a workaround than an answer but as you re able to use wmi why not try to create the remote process with it? Have a look here http://www.lazywinadmin.com/2011/06/powershell-launchstart-process-on.html?m=1
After comments exchange, the problem is that you had not provide a credential with administrative privilege for the remote host.
Have you set the TrustedHosts on your computer to allow you to connect to other computers?
Run this on the computer you are trying to remote from.
Set-Item wsman::localhost\client\TrustedHosts *
Restart-Service WinRm
One thing is clear, the error message "The network path was not found" gives no indication of what the underlying issue is. I saw a post in a Microsoft forum where a respondent stated it used to work and now did not. That is where I found myself. I verified that I could ping and that I could net view shares, so I knew that the network portions were functional. I rebooted the source server and that did not seem to help. Once I rebooted the target server, the WinRM error went away and everything started to work again. It is not clear whether a service was down or misbehaving or if there was something less obvious going on. After the reboot I got one more failure (out of about 20 attempts), but random failures are not so uncommon in our environment.
I will leave this behind just in case it helps someone else.