PowerShell Remoting

In this tutorial we will see about PowerShell Remoting and its use. Using Windows PowerShell, we are able to connect on remote computers / server and run commands on them. As we have discuss in Windows PowerShell Sessions – PSSessions tutorial, we are able to create an interactive, temporary or persistent connection to the remote system and perform our tasks. Each method has its benefits. There are some cmdlets, that can accept ComputerName as parameter. Those cmdlets do not use Windows PowerShell Remoting. First we need to see what are the requirements of PowerShell Remoting.

System Requirements

In order to run remote sessions on Windows PowerShell 3.0, both local and remote computers must have installed:

• Windows PowerShell 3.0 or later
• Microsoft .NET Framework 4 or later
• Windows Remote Management 3.0

In order to run remote sessions on Windows PowerShell 2.0, both local and remote computers must have installed:

• Windows PowerShell 2.0 or later
• Microsoft .NET Framework 2.0 or later
• Windows Remote Management 2.0

The reason we separate the two above, is because there are some new features that were introduced in Windows PowerShell 3.0. As we have discussed also in Windows PowerShell Sessions – PSSessions tutorial, sessions, beginning Windows PowerShell 3.0, are independent from local computer and they are maintained on remote computer instead of the local one. You are able to have a session between computers running Windows PowerShell 2.0 and Windows PowerShel 3.0, but you will have available only Windows PowerShell 2.0 features.

You are able to find the version of Windows PowerShell that you have installed by using $PSVersionTable. It is an automatic variable. If you want to see all the information that is included in this variable you can just type the variable in Windows PowerShell console.

If you want to see only Windows PowerShell version, then you can use the below:

Code:

$PSVersionTable.PSVersion

Output:

[adinserter name=”In Article”]

User Permissions Requirements

By default, in order to be allowed to create sessions, you need to be a member of Administrators group on the remote computer / server, or be able to provide the credentials of an administrator account. The security descriptor of session configuration determines who has access to create session on the machine and run commands. By default, this is set to Administrators groups. You are able to modify this to enable other users, that are not included in Administrators group to connect and run commands on the remote computer. 

Enable PowerShell Remoting

If you want to establish a connection to a remote computer, you do not need to have PowerShell Remoting on your computer. But, in order for a computer to receive a connection you need to have PowerShell Remoting enabled on that computer. Also if you want to have a PSSession on local computer, then you need to enable PowerShell Remoting again. 

You are able to enable PowerShell Remoting by using Enable-PSRemoting. You need to run Windows PowerShell as Administrator in order to do that. From Windows Server 2012 and later, PowerShell Remoting is enabled by default. For the rest of the supported versions you have to run Enable-PSRemoting to enable it. As Microsoft provides, the remoting features of Windows PowerShell are supported by the WinRM service, which is the Microsoft implementation of the Web Services for Management (WS-Management) protocol. When you enable Windows PowerShell remoting, you change the default configuration of WS-Management and add system configuration that allow users to connect to WS-Management. The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS. You can find a guide on how you can enable WinRM over HTTPS here and in related links sections.

Firewall changes

From Windows PowerShell 3.0, Enable-PSRemoting cmdlet enables remoting on client and server versions of Windows on private, domain, and public networks. Below is the information provided by Microsoft on what changes are applied on Windows firewall when you run Enable-PSRemoting.

On server versions of Windows with private and domain networks, the Enable-PSRemoting  cmdlet creates firewall rules that allow unrestricted remote access. It also creates a firewall rule for public networks that allows remote access only from computers in the same local subnet. This local subnet firewall rule is enabled by default on server versions of Windows on public networks, but Enable-PSRemoting reapplies the rule in case it was changed or deleted. In Windows PowerShell 2.0, on server versions of Windows, Enable-PSRemoting creates firewall rules that permit remote access on all networks. 

On client versions of Windows with private and domain networks, by default, the Enable-PSRemoting cmdlet creates firewall rules that allow unrestricted remote access. To enable remoting on client versions of Windows with public networks, use the SkipNetworkProfileCheck  parameter of the Enable-PSRemoting  cmdlet. It creates a firewall rule that that allows remote access only from computers in the same local subnet. To remove the local subnet restriction on public networks and allow remote access from all locations on client and server versions of Windows, use the Set-NetFirewallRule  cmdlet in the NetSecurity module. Run the following command:

<em>Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any</em>

In Windows PowerShell 2.0, on client versions of Windows, Enable-PSRemoting creates firewall rules only on private and domain networks. If the network location is public, Enable-PSRemoting  fails.

[adinserter name=”In Article”]

Running commands on remote computer

There are several ways to run commands on remote computers.

• You can start an interactive session by using Enter-PSSession cmdlet

• By using Invoke-Command , to run a command or script, using a temporary connection

• By using a PSSession, to run multiple commands, script block or script, using persistent connection. You can find more information about PSSessions in Windows PowerShell Sessions – PSSessions tutorial.

[adinserter name=”In Article”]

PowerShell Remoting Security

PowerShell Remoting by default only allow users that are members in Administrators group. Sessions are under user’s context, so all system access controls are applied to PowerShell Remoting also. As we mentioned before, on private networks, the default Windows Firewall rule for PowerShell Remoting accepts all connections. On public networks, the default Windows Firewall rule allows PowerShell Remoting connections only from within the same subnet. You have to explicitly change that rule to open PowerShell Remoting to all connections on a public network.

Below is a warning from Microsoft:

Warning: The firewall rule for public networks is meant to protect the computer from potentially malicious external connection attempts. Use caution when removing this rule.

Below are the ports that PowerShell Remoting and WinRM are listening:

• HTTP: 5985
• HTTPS: 5986

The process runs isolated. PowerShell Remoting users Windows Remote Management (WinRM) to communicate and WinRM runs as a service under the Network Service account. WinRM create isolated processes, that run as the user account for the PowerShell instance. PowerShell Instance that runs under one user, has no access to any process that is running PowerShell of another user.

Now lets see the security of the communication.

PowerShell Remoting Encryption

We will divide the PowerShell Remoting security into two sections.

1. Initial Authentication
2. Ongoing Communication

Ongoing Communication

First we will take the Ongoing Communication. After PowerShell Remoting will complete the initial authentication, IT ill encrypt all communication with a per-session AES-256 symmetic key. It does not matter if you are using HTTP or HTTPS, PowerShell Remoting will keep encrypting the communication.

[adinserter name=”In Article”]

Initial Authentication

In general, authentication is used to confirm the identity of the client to the server and vice versa.

When you are using the computer name to connect to the remote domain joined server, the default authentication protocol of PowerShell Remoting is Kerberos. Kerberos guarantees both the user identity and server identity without sending any sort of reusable credential.

When you will connect to a domain server using the IP address or to a workgroup server, PowerShell Remoting will use NTLM authentication.The NTLM authentication protocol guarantees the user identity without sending any credentials. As Microsoft provides, To prove user identity, the NTLM protocol requires that both the client and server compute a session key from the user’s password without ever exchanging the password itself. The server typically does not know the user’s password, so it communicates with the domain controller, which does know the user’s password and calculates the session key for the server. The NTLM protocol does not, however, guarantee server identity.

As with all protocols that use NTLM for authentication, an attacker with access to a domain-joined computer’s machine account could invoke the domain controller to compute an NTLM session-key and thereby impersonate the server. NTLM-based authentication is disabled by default, but may be permitted by either configuring SSL on the target server, or by configuring the WinRM TrustedHosts setting on the client.

As per Microsoft:

Using SSL certificates to validate server identity during NTLM-based connections

Since the NTLM authentication protocol cannot ensure the identity of the target server (only that it already knows your password), you can configure target servers to use SSL for PowerShell Remoting. Assigning a SSL certificate to the target server (if issued by a Certificate Authority that the client also trusts) enables NTLM-based authentication that guarantees both the user identity and server identity.

Ignoring NTLM-based server identity errors

If deploying a SSL certificate to a server for NTLM connections is infeasible, you may suppress the resulting identity errors by adding the server to the WinRM TrustedHosts list. Please note that adding a server name to the TrustedHosts list should not be considered as any form of statement of the trustworthiness of the hosts themselves – as the NTLM authentication protocol cannot guarantee that you are in fact connecting to the host you are intending to connect to. Instead, you should consider the TrustedHosts setting to be the list of hosts for which you wish to suppress the error generated by being unable to verify the server’s identity

[adinserter name=”In Article”]

Second Hop Problem

As we mentioned above, the two methods that PowerShell Remoting uses, do not send any credentials to the remote computer. So when we want to connect from the remote computer to another computer it fails. The remote computer does not know the user credentials to use them to connect to another remote server as  our user. There are some ways that we can overcome this issue. Lets see the list below:

• CredSSP
• Kerberos delegation (unconstrained)
• Kerberos constrained delegation
• Resource-based Kerberos constrained delegation
• PSSessionConfiguration using RunAs
• Just Enough Administration (JEA)
• Pass credentials inside an Invoke-Command script block

Each of the above ways has its pros and cons. So it depends on you which one you will use based on what you want to achieve and how you want to work. I will not go in detail for the methods but I will provide you below the pros and cons for each one along with some details, as provided by Microsoft. In related links section you can find all related information and some examples of the methods.

CredSSP

You can use the Credential Security Support Provider (CredSSP) for authentication. CredSSP caches credentials on the remote server (ServerB), so using it opens you up to credential theft attacks. If the remote computer is compromised, the attacker has access to the user’s credentials. CredSSP is disabled by default on both client and server computers. You should enable CredSSP only in the most trusted environments. For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted.

Pros:

• It works for all servers with Windows Server 2008 or later.

Cons:

• Has security vulnerabilities.
• Requires configuration of both client and server roles.

Kerberos delegation (unconstrained)

This method provides no control of where delegated credentials are used.

Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated.

Pros:

• Requires no special coding.

Cons:

• Does not support the second hop for WinRM.
• Provides no control over where credentials are used, creating a security vulnerability.

[adinserter name=”In Article”]

Kerberos constrained delegation

Not resource-based

Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. 

Pros:

• Requires no special coding

Cons:

• Does not support the second hop for WinRM.
• Must be configured on the Active Directory object of the remote server (ServerB).
• Limited to one domain. Cannot cross domains or forests.
• Requires rights to update objects and Service Principal Names (SPNs).

Resource-based Kerberos constrained delegation

Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. In the second hop scenario described above, you configure ServerC to specify from where it will accept delegated credentials.

Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated.

Pros:

• Credentials are not stored.
• Relatively easy to configure by using PowerShell cmdlets–no special coding required.
• No special domain access is required.
• Works across domains and forests.
• PowerShell code.

Cons:

• Requires Windows Server 2012 or later.
• Does not support the second hop for WinRM.
• Requires rights to update objects and Service Principal Names (SPNs).

[adinserter name=”In Article”]

PSSessionConfiguration using RunAs

You can create a session configuration on ServerB and set its RunAsCredential parameter.

Pros:

• Works with any server with WMF 3.0 or later.

Cons:

• Requires configuration of PSSessionConfiguration and RunAs on every intermediate server (ServerB).
• Requires password maintenance when using a domain RunAs account

Just Enough Administration (JEA)

JEA allows you to restrict what commands an administrator can run during a PowerShell session. It can be used to solve the second hop problem.

Pros:

• No password maintenance when using a virtual account.

Cons:

• Requires WMF 5.0 or later.
• Requires configuration on every intermediate server (ServerB).

[adinserter name=”In Article”]

Pass credentials inside an Invoke-Command script block

Pros:

• Does not require special server configuration.
• Works on any server running WMF 2.0 or later.

Cons:

• Requires an awkward code technique.
• If running WMF 2.0, requires different syntax for passing arguments to a remote session.

PowerShell Remoting Over SSH

You are also able to use PowerShell Remoting for Linux and MacOS. This can be done by using PowerShell Remoting over SSH. As this is still an early stage for this method, PowerShell Remoting over SSH does not currently support remote endpoint configuration and JEA (Just Enough Administration).

As Microsoft describes:

SSH remoting lets you do basic PowerShell session remoting between Windows and Linux machines. SSH Remoting creates a PowerShell host process on the target machine as an SSH subsystem. Eventually we’ll implement a general hosting model, similar to WinRM, to support endpoint configuration and JEA.

You can find the guide on how to setup this method on Windows, Linux and MacOS machines in this link. I have included it also in related links section.

I hope the tutorial about PowerShell Remoting is helpful.

Please let me know your comments and thoughts.

You feedback is appreciated.

[adinserter name=”In Article”]

Related Links:

• PowerShell Tutorials
• PowerShell Scripts
• Windows PowerShell Sessions – PSSessions
• about_Remote | Microsoft Docs
• about_Remote_Requirements | Microsoft Docs
• about_Remote_Troubleshooting | Microsoft Docs
• about_Remote_FAQ | Microsoft Docs
• about_Remote_Disconnected_Sessions | Microsoft Docs
• about_Remote_Output | Microsoft Docs
• about_Remote_Jobs | Microsoft Docs
• about_Remote_Variables | Microsoft Docs
• How To: Configure WINRM for HTTPS – Microsoft Support
• Credential Security Support Provider | Microsoft Docs
• Enable PowerShell “Second-Hop” Functionality with CredSSP – Hey, Scripting Guy! Blog
• PowerShell Remoting Over SSH | Microsoft Docs
• Invoke-Command – Microsoft Docs
• Enter-PSSession – Microsoft Docs
• New-PSSession – Microsoft Docs
• New-PSSessionOption – Microsoft Docs
• Connect-PSSession – Microsoft Docs
• Disconnect-PSSession – Microsoft Docs
• Exit-PSSession – Microsoft Docs
• Get-PSSession – Microsoft Docs
• Receive-PSSession – Microsoft Docs
• Remove-PSSession – Microsoft Docs
• Get-ChildItem – Microsoft Docs
• Rename-Item – Microsoft Docs
• Write-Host – Microsoft Docs
• Get-Content – Microsoft Docs
• Set-Location – Microsoft Docs

[adinserter name=”Matched-Content”]

Summary

Article Name

PowerShell Remoting

Description

PowerShell Remoting. In this tutorial you will find information about PowerShell Remoting and its use. Stephanos Constantinou Blog

Author

Stephanos

Publisher Name

Stephanos Constantinou Blog

Publisher Logo