PowerShell Remoting (PSRemoting) is one of the most-used features in all of PowerShell. Why? Because it’s so darn useful! Using a single command, you can seamlessly connect to one or thousands of remote computers and execute commands.
In this Ultimate Guide, you will go deep into PSRemoting. You’ll learn what it is, how it works, and all of the various technologies that make PSRemoting work. This guide will not cover how to use PSRemoting. You’ll see plenty of references to many of our how-to guides throughout.
In a nutshell, PSRemoting allows you to run commands on remote computers just as if you were sitting in front of them. PSRemoting provides a set of features that connects and authenticates a user user, runs remote commands and returns any output from that command to the local computer.
Think of PSRemoting like telnet or SSH or even psexec. It’s just a way to run commands on computers within PowerShell.
PSRemoting heavily relies on a concept called a session. A session is a term used to describe a remote shell that runs commands inside. The process to create one of these sessions goes through many steps in the background.
When you initiate a PSRemoting session, the following rough steps carry out:
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
You can discover all of the WinRm listeners running on any Windows computer by using the winrm command below.
winrm e winrm/config/listener
WinRm listeners have a few important components. They have:
Use an HTTPS listener when possible. Setting up HTTPS transport increases security by ensuring server validity and encrypting both the authentication and transport traffic. When issuing a certificate, use a trusted certificate from a certification authority, when possible rather than a self-signed certificate.
As stated above, one of the first steps that PSRemoting goes through is authentication. Authentication is one of the most complicated yet most essential parts of PSRemoting.
When PSRemoting was first introduced, it only had one authentication mechanism, Windows Remote Management (WinRM) but nowadays, you can also authenticate using SSH which you’ll see later.
WinRM supports two distinct types of authentication; a username and password or a certificate with various types of authentication for a username/password combination.
Starting at the easiest, yet most insecure type of authentication is Basic authentication. This type of authentication is a standard built into the HTTP protocol. Basic authentication sends a base64 encoded copy of the username and password in the HTTP header from the client to the listener.
Because Basic authentication only encodes the username and password and does not encrypt it, it’s trivial to intercept the credentials over the network.
Do not use Basic authentication unless you absolutely have to. There are many other more secure methods WinRM can authenticate!
Are both your client and server in an Active Directory environment? If so, you’re using already using Kerberos authentication across many of your network services.
When the WinRM client attempts to connect to a WinRM listener over Kerberos:
During Kerberos authentication, the domain controller validates both the client and server during the ticket retrieval steps stopping someone malicious from impersonating the server.
Kerberos is a mature and secure authentication method and is the default authentication type when a client and server are both members of an Active Directory domain. But, it does require both client and server to be joined to the same Active Directory forest or with a trust set up between forests.
WinRm can also attempt to use Kerberos and if not available fall back and attempt to use an authentication protocol called NT Lan Manager (NTLM).
When using NTLM:
NTLM is good for validating the client, but unlike Kerberos, it does not validate the server. This opens up multiple attacks where the server could be impersonated by an attacker.
You can improve NTLM security by also validating the server with a server authentication certificate and assigning it to an HTTPS WinRM listener. In this setup, the client is authenticated with NTLM against the domain controller, and the server is authenticated with a trusted certificate. Although this setup provides both client and server authentication, the NLTM protocol uses an older encryption cipher with an outdated key size.
For these reasons, NLTM is only usable if you add the server to the trusted host list or use an HTTPS listener.
One of the most uncommon authentication methods to use in WinRM is Digest authentication. NTLM and Digest are similar authentication methods. Like NTLM, Digest generates a unique string that is encrypted with the hash of the user’s password. The password then doesn’t need to be sent to the server.
Digest uses the MD5 hashing algorithm to encrypt the password. Due to this choice of algorithm, Digest is generally seen as obsolete and should not be used. MD5 has various known vulnerabilities that make it unsuitable for cryptographic use.
Although we could go into the ins and outs of CredSSP, it’s not necessary. Why? Because when it comes to PSRemoting and WinRM, CredSSP is implemented for typically one reason, the “second hop problem” which you’ll learn about below.
When configured for CredSSP authentication, the WinRM client and server both use Negotiate authentication to authenticate both the user and client. But once completed, the user’s password is sent to the server.
Because the password is sent after the authentication process has been completed, it is now encrypted. CredSSP also encrypts the password with the TLS session keys so that the encrypted string will be unique between sessions.
CredSSP is helpful because after authentication, the server can then connect to anything else on your behalf. However, when this happens, you are fully trusting the server you connected to with the user password.
Arguably the most secure method of authentication to use with PSRemoting is certificate-based authentication. In this method of authentication, a typical key exchange happens with a private and public key on the client and a server validating the certificate.
WinRM authenticates the user by mapping a user on the server within WinRm. The only thing that is passed during the authentication process is the public key so it is a very secure way to authenticate
Although the most secure, certificate-based authentication is not too common. Why? Simply because of the leg work necessary to set it up. You must:
You cannot use a domain user to authenticate with certificates even if the client and server are both a part of Active Directory.
Now that you’ve seen there are many different authentication options available, how do you know which are available out-of-the-box? Below you’ll see a table with two columns indicating if the WinRM client, by default, is enabled and if that particular authentication type is enabled by default.
All of the aforementioned authentication types are configurable but using the table below will give you a good idea of what you’ll need to configure yourself.
Next if that module is imported, I can then execute the Test-PendingReboot command. This is shown below, but you will notice that it shows that the computer name in the output is not the name of the device that PowerShell is running from, but the device that the command was imported from.
Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.
