Sign in Subscribe
ansible

WinRM - Remote Management of Windows

How to configure the WinRM Service correctly with a Powershell Script. Quick, easy and fast (SSL encryption).

Roman Hüsler

• 6 min read
WinRM - Remote Management of Windows

Today it is about the automatic WinRM configuration. If WinRM is configured correctly, you can connect to a remote computer using Powershell.

This blog is also relevant if you use configuration management and automation tools like Ansible with Windows servers – the configurations are made using the WinRM interface.  Windows can be completely remote managed by using the winrm interface. However, correct configuration is important.

$cred = get-credential remoteComputer\administrator
enter-pssession -computername remoteComputer -credential $cred
Image – Remote Management of a Windows Client

This blog is about how to correctly configure WinRM with encryption and authentication provider. We will make the following configurations:

  • Configuration WinRM service
    Turn on services
  • Windows firewall configuration
    Allow traffic on port 5986
  • Configuration WinRM listener and SSL certificates
    Only allow encrypted traffic
  • Configuration WinRM Authentication Provider
    We use CredSSP

We also have a script that does all the configuration automatically and which can be included in the GPO.

Content

Windows Remote Management Service (WinRM)

WinRM is a remote management protocol built into Windows. It is essentially based on the SOAP protocol and SOAP in turn is based on the HTTP(s) protocol.

With the help of WinRM, the configuration parameters of Windows can be queried and managed, also over the network. Starting with Windows 10, WinRM must be explicitly activated and configured. In order to take security into account, it is therefore important to make the configurations correctly.
opensight.ch – roman hüsler

WinRM uses ports 5985 (HTTP) and 5986 (HTTPS) for communication. Of course, we would like to configure the WinRM service in the course of this blog in such a way that only encrypted communication with the clients / servers is possible.

Manual WinRM Configuration

Configure WinRM Service

The service should run and be started automatically at Windows startup.

Set-Service -Name WinRM -StartupType Automatic
Set-Service -Name WinRM -Status Running

Configuration WinRM listener and SSL certificates

First, of course, we log on to the Windows computer on which WinRM is to be configured manually. Then we make sure that only encrypted communication with WinRM is possible.

# Deactivation of unencrypted Endpoints
Set-WSManInstance winrm/config/Listener -SelectorSet @{Address='*';Transport="HTTP"} -ValueSet @{Enabled="false"}

Now we need to have a certificate for running WinRM service on the Windows computer. A self-signed certificate can be issued for this purpose. Of course, it’s better to use your domain’s CA to issue a certificate.

Use of a self-signed certificate
The subject name of the generated certificate should match the FQDN of the computer, otherwise there will be problems later. We define the extension “2.5.29.37” (Key Usage) with the value “{text}1.3.6.1.5.5.7.3.1” (Server Authentication).

# generate self signed cert
$fqdn = "bnetcli01.bnet.local"
$cert = New-SelfSignedCertificate -Subject ("CN=$fqdn") -TextExtension '2.5.29.37={text}1.3.6.1.5.5.7.3.1' -CertStoreLocation Cert:\LocalMachine\My

# WinRM HTTPS Listener Configuration
New-WSManInstance winrm/config/listener -SelectorSet @{Address="*";Transport="HTTPS"} -ValueSet @{Hostname=$fqdn;CertificateThumbprint=$cert.Thumbprint}

Using a host certificate from the CA
If you have a CA, you should have a host certificate issued for the computer and then use this for the encrypted communication of the WinRM service. You can see how to configure the CA in the “CA configuration” chapter. When this is done, you can configure the WinRM HTTPS listener with the CA’s certificate.

# list trusted root certs
$trustedRootCerts = (get-childitem -Path Cert:\localmachine\root) | ForEach-Object { $_.Subject }

[String] $HostName = "bnetcli01.bnet.local"
[String] $Thumbprint = (get-childitem -Path Cert:\localmachine\my | Where-Object {
                    ($_.Issuer -in $trustedRootCerts) -and
                    ($_.Extensions.EnhancedKeyUsages.value -eq '1.3.6.1.5.5.7.3.1') -and
                    ($HostName -in $_.DNSNameList.Unicode.toLower()) -and
                    ($_.Subject.ToLower() -like "cn=$HostName") } | Select-Object -First 1
).Thumbprint
New-WSManInstance winrm/config/listener -SelectorSet @{Address="*";Transport="HTTPS"} -ValueSet @{Hostname=$HostName;CertificateThumbprint=$Thumbprint}

Authentication Provider

WinRM supports various authentication mechanisms. In this blog article we will use CredSSP.

  • Basic
    The simplest method and also the least secure. Username and password are simply Base64 encoded and sent over the network. This is particularly problematic in combination with unencrypted communication (HTTP).
  • Certificate
    Certificates (similar to SSH key pairs) are used for authentication.
  • NTLM
    NTLM is an older authentication mechanism from Microsoft and can be used to authenticate both local and domain accounts.
  • Kerberos
    Recommended as an authentication mechanism in Windows Domain Environments.
  • CredSSP
    A newer authentication protocol.

We make sure that the basic authentication cannot be used and turn on the CredSSP authentication provider.

# basic auth deactivation
set-item -Path WSMan:\localhost\Service\Auth\Basic -Value false
set-item -Path WSMan:\localhost\Service\Auth\CredSSP -Value true
restart-service -ServiceName WinRM

Windows Firewall

Allow inbound traffic on port 5986.

$FirewallParam = @{
    DisplayName = 'Windows Remote Management (HTTPS)'
    Direction = 'Inbound'
    LocalPort = 5986
    Protocol = 'TCP'
    Action = 'Allow'
    Program = 'System'
}
New-NetFirewallRule @FirewallParam

Configuration CA

Now we should make sure that every Windows 10 client that we want to access later has a valid computer certificate. We assume you already have a CA set up on a server in your domain. In our Certificate Authority we “right click” on “Certificate Templates” and select “Manage”. After that we clone the “Web Server” template.

Image - Windows Server Certificate Template

The following configurations are to be made:

  • “General” tab
    Name: WinRM
  • “Subject Name” tab
    Activate “Build from this Active Directory Information”.
  • “Subject name format”: “Common Name”
    Just tick “DNS Name”.
  • “Security” tab
    Domain Computers: Read, Enroll and Autoenroll permissions

Now the certificate can be issued to all clients. Select “Certificate Template to Issue” and then select the template you just created. If you now reboot one of your Windows 10 computers, it should automatically receive a device certificate.

Image - Windows Server Issue Certificates by Certificate Template

WinRM Settings check

Now it’s time to double check that all the settings are correct.

# WinRM Listener check
winrm enumerate winrm/config/Listener

# WinRM Authenticator check
winrm get winrm/config/Service

As desired, the HTTP listener is disabled (you can also remove it completely) and the thumbprint of the certificate to be used is entered for the HTTPS listener, which is located in the “LocalMachine” certificate store. (picture below)

Image – WinRM Listener settings check
Image – WinRM Service settings check

Verify access

Now let’s try WinRM and access Windows 10 client from a remote system to run “ipconfig” command. To do this we will use the following commands:

$username = "domain\username"
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username,$password
Invoke-Command -ComputerName remoteComputer -UseSSL -ScriptBlock { ipconfig } -Credential $cred

As can be seen in the picture, the attempt to connect initially did not work. The reason:
In this case, a self-signed certificate was generated for WinRM on the remote computer. This must be exported from the certificate store on the remote computer and entered into the “Trusted Root” store on the accessing system. With a certificate issued by the domain CA, this would not be a problem. The certificate of the domain CA is usually already entered in the Trusted Root Store on all Windows clients that are members of the domain.

Image - Testing WinRM

Automatic WinRM configuration

In order to do all mentioned configuration automatically we created a Powershell script for automatic WinRM configuration. You can include this in the GPO, for example, as a logon script (use at your own risk).

The script is available free of charge from our downloads and it automatically makes the following settings:

  • Configure WinRM Windows Service
    Make sure the service is enabled and startup is automatic
  • Configure Windows Firewall
    Allow traffic on port 5986 with rule ‘Windows Remote Management (HTTPS)’
  • WinRM Listener Configuration and SSL Certificates
    Only allow encrypted traffic on port 5986. If possible, use the Cert from Domain CA (this CA has to be configured manually of course). If no CA Cert is available, create a self-signed cert (friendly name: ‘OpensightWinRMHostCert’)
  • WinRM Authentication Provider Configuration
    Make sure basic authentication is switched off and credssp is switched on
Automatic WinRM Configuration

Sign up for more like this.

Enter your email
Subscribe