Enabling Powershell Remoting

To totally unlock this section you need to Log-in.

To enable Powershell remoting, you need run the following cmdlet:

Enable-PSRemoting

In workgroup environments, enable classic mode authentication for network logon:

  • Open Local Security Policy from the Control Panel and select Administrative Tools.
  • Navigate to Local Policies \ Security Options.
  • Double-click Network Access: Sharing and Security Model for local accounts and set it to classic.

Modify the WSMan trusted hosts setting, by adding the IP addresses of all remote clients to the list of trusted hosts. This can be done using one of the following commands:

Set-item wsman:localhost\client\trustedhosts -value * (adds all computers as trusted hosts)
Set-item wsman:localhost\client\trustedhosts -value Computer (only adds Computer to the trusted hosts)
Set-item wsman:localhost\client\trustedhosts -value *.domain.com (adds all computers in the specified domain)
Set-item wsman:localhost\client\trustedhosts -value 10.10.10.1 (adds the remote computer with the IP address 10.10.10.1 to the trusted hosts list).

Enabling Remoting Using GPO (Group Policy Objects)

While remoting can be enabled manually using Enable-PSRemoting, it is recommended to use GPO management tools whenever it is possible. Use GPO to apply policies on a single host (for example, the target PowerShell host) or a group of servers.

Group Policy Configuration for a Single Host

To enable PowerShell remoting for a single host:

  • Open the Group Policy Management console. For example, gpedit.msc.
  • Go to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components.

Enabling Powershell Remoting

From the Windows Components listed in the right pane, we are interested in two of them. The first one is Windows Remote Management (WinRM) and the second one is Windows Remote Shell. The next step will refer to the first one, therefore browse the components and open Windows Remote Management (WinRM).

Enabling Powershell Remoting

WinRM is the service that PowerShell uses for remote sessions. WinRM can be configured as client or service, depending on the role the host is going to have in a PowerShell connection (for example, request access to execute scripts on other hosts or allow other hosts to execute scripts on the current host).

At this point, you can enable different authentication types, specify the trusted hosts, enable HTTP or HTTPS listeners, and so on.

There are some other default settings the user might want to change in a production environment. These settings can be found in Windows Remote Shell as shown below:

You can specify the maximum number of remote shells per user (default is 2) or the maximum amount of memory in MB for shell (the default is 150). After configuring the GPO, you might need to restart the computer in order to apply the policies or try to run the command gpupdate.

Group Policy Configuration for a Group of Servers

Sometimes the GPO policies must be applied on multiple server hosts and repeating the above steps on every server might not be the best solution. Therefore, you can create a new GPO policy, configure it and apply it on a list of servers.

Go to the domain controller or on a server where gpmc.msc is available and open it.

Right-click the Group Policy Object item as in the following image and choose New. Enter the name for the new GPO and select the policy to inherit from, and then go to the next step.

Enabling Powershell Remoting

Right-click the new GPO and select Edit.

Enabling Powershell Remoting

Configure the GPO same way as for single hosts.

Now that there is a new GPO, you can apply it to a group of servers. The following example shows you how to link it on an existing OU from AD; however, this can be applied to other groups as well. The GPO interface displays the existing OUs from the domain controller AD.

To link a GPO to an OU, go to that OU, right click it and select Link an Existing GPO.

Enabling Powershell Remoting

The GPO settings will be applied to all servers contained in the selected OU. Although a GPO update might be required and also a reboot for the servers before the policies are actually applied.

NOTE: remember that local policies overwrite domain policies.

Enabling Remoting for Non-Administrative Users

To establish a PSSession or run a command on a remote computer, you must have permission to use the session configurations on the remote computer.

By default, only members of the Administrators group on a computer have permission to use the default session configurations. Therefore, only members of the Administrators group can connect to the computer remotely.

To allow other users to connect to the local computer, give the user Execute permissions to the default session configurations on the local computer.

The following command opens a property sheet that lets you change the security descriptor of the default Microsoft.PowerShell session configuration on the local computer.

Set-PSSessionConfiguration Microsoft.Powershell –ShowSecurityDescriptorUI

Enabling Powershell Remoting

Authentication Types

Basic

Client side steps:

Allow unencrypted communication for the client, by running the following PowerShell command:

set-item wsman:\localhost\client\AllowUnencrypted -value true

Enable Basic authentication for the client, by running the following PowerShell command:

set-item wsman:\localhost\client\auth\Basic -value true

Server side steps:

Turn off encryption for the WinRM service, by running the following PowerShell command:

set-item wsman:\localhost\service\AllowUnencrypted -value true

Enable Basic authentication for the service, by running the following PowerShell command:

set-item wsman:\localhost\service\auth\Basic -value true

NOTE

  • The client and server can be in different domains.
  • When using Basic authentication, a local user account must be provided for authentication on the remote host.
    Basic can be used when the destination is an IP address.
    Basic can be used when the destination is one of the following: localhost, 127.0.0.1, [::1].
    The cluster name, as well as the hostnames of the cluster nodes can be used for the destination host.

CredSSP

Client side steps:

Enable CredSSP authentication for the client, by running the command:

Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/*.

Allow delegating fresh credentials by performing the following steps.

  • Open gpedit.msc.
  • Go to Computer Configuration > Administrative Templates > System > Credentials Delegation.
  • Enable Allow Delegating Fresh Credentials and add the wsman hosts to the server list.
  • Run gpupdate /force from command line to force policy update.

Server side steps:

Enable CredSSP authentication, by running the following PowerShell command:

Enable-WSManCredSSP -Role Server

Create a new https listener by using the following commad:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS.

Domain Controller side steps:

If the NETWORK SERVICE doesn’t have “Validated write to service principal name“, do one of the following:

Try running the following command:

dsacls “CN=AdminSDHolder,CN=System,DC=domain,DC=com” /G “Sn-1-5-20:WS;Validated write to service principal name”

Open ADUC, go to Computers > DC object > Security, select Network Service and give it Validated write to SPN.

Default

When Default authentication is used, the following situations can occur:

  • Kerberos is the method of authentication used if the client is in the same domain as the destination host, and the value specified for that host is not one of the following: localhost, 127.0.0.1, [::1].
  • Negotiate is the method of authentication used if the client is not in the same domain as the destination host, or the value specified for that host is one of the following: localhost, 127.0.0.1, [::1].

Digest

Digest authentication is not supported for remote connections. It cannot be configured for the WinRM server component.

Kerberos

Client side steps:

Enable Kerberos authentication for the client, by running the following PowerShell command:

set-item wsman:\localhost\client\auth\Kerberos -value true

Server side steps:

Enable Kerberos authentication for the service, by running the following PowerShell command:

set-item wsman:\localhost\service\auth\Kerberos -value true

NOTE

  • The client and server must be in the same domain.
  • Either a local or a domain user account can be provided for authentication on the server host.
  • Kerberos cannot be used when the destination is an IP address.
  • Kerberos cannot be used when the destination is one of the following: localhost, 127.0.0.1, [::1].
  • The cluster name cannot be used to specify the host. Only the hostnames of the cluster nodes can be used for the destination host.

Negotiate

Client side steps:

Enable Negotiate authentication for the client, by running the following PowerShell command:

set-item wsman:\localhost\client\auth\Negotiate -value true

Server side steps:

Enable Negotiate authentication for the service, by running the following PowerShell command:

set-item wsman:\localhost\service\auth\Negotiate -value true

NOTE

  • The client and server can be in different domains.
  • Either a local or a domain user account can be provided for authentication on the server host. Local accounts can only be provided when connecting to the localhost.
  • Negotiate can be used when the destination is an IP address.
  • Negotiate can be used when the destination is one of the following: localhost, 127.0.0.1, [::1].
  • The cluster name, as well as the host names of the cluster nodes can be used for the destination host.

NegotiateWithImplicitCredential

When using NegotiateWithImplicitCredentials, no credentials should be provided. The current logged-on user account will be used for authentication. This can either be a local or a domain user account.

NegotiateWithImplicitCredential can only be used when the destination is one of the following: localhost, 127.0.0.1, [::1].