Status: DRAFT
To keep things simple, we will start with the default configuration of WinRM. This enables some insecure connection methods, but these will be disabled immediately:
PS > winrm quickconfig
It is very important that you know you are connecting to the correct server. If the client does not verify the server, you could send commands to the remote server that might disclose sensitive information.
This step will ensure that your server's identity can be verified, but note that servers not under your control may still enable connection methods that prevent the client from verifying that server. So always double-check that you use the correct connection method on the client. The chapter about Windows client configuration explains how to force the use of HTTPS.
The server is now listening for HTTP connections on port 5985. Clients cannot verify the server identity when using HTTP, so the HTTP connection method has to be disabled:
PS > winrm delete WinRM/Config/Listener?Address=*+Transport=HTTP
The firewall rules for the HTTP connection method can also be removed. There are rules for modern and backward-compatible configurations, and all of them will be deleted.
The name of the backward-compatible rule(s) is language-dependent. The second command can be used to find out the actual name of these rules.
PS > netsh advfirewall firewall delete rule name='Windows Remote Management (HTTP-In)'
PS > netsh advfirewall firewall show rule name=all | Select-String 'Windows Remote Management'
PS > netsh advfirewall firewall delete rule name='Windows Remote Management - <language-dependent name> (HTTP-In)'
Clients should be able to connect to a server without having to send the user's credentials. And the attack surface of a server should be minimized. So only a minimal and secure set of authentication methods should be enabled.
This step will ensure that your server is properly configured, but servers not under your control may still allow insecure authentication methods. So always double-check that you use the correct authentication method on the client. In the chapter about Windows client configuration, the authentication methods that the WinRM client may use are limited.
This step is to make sure that only the desired authentication methods are enabled. The insecure ones should be disabled by default. Certificate authentication is disabled by default too, so it needs to be enabled.
To inspect the current settings run this command:
PS > winrm get WinRM/Config/Service/Auth
To allow clients to authenticate using certificates only the certificate authentication method has to be enabled.
Negotiate authentication is needed to be able to (amongst others) locally configure WinRM using the winrm command.
Leaving Negotiate authentication on does not result in a security risk as no sensitive information of the server is leaked when a client forces the use of it.
Whether other authentication methods need to be enabled depends on your environment. For example: Kerberos authentication is used in environments with Active Directory Domain Services, so it is very likely that it must be enabled in such environments.
The methods that must be disabled unless they are needed for a specific use case, are basic and credential security support provider (CredSSP). Basic authentication will send your password to the server. CredSSP will send your credentials to the server:
PS > winrm set WinRM/Config/Service/Auth '@{Basic="false";Kerberos="false";Negotiate="true";Certificate="true";CredSSP="false"}'
This step changes the network category of your network connection(s) (if needed). In most cases Windows will have determined the correct network cateogry, but there are some situations (working with virtual machines, for example) where Windows chooses the incorrect network category.
Never change the network category from public to private if you are not actually on a private network. Windows will expose a lot more services on a private network, greatly increasing your attack surface.
WinRM will not allow connections from public networks. In most cases the network connection(s) will be private or domain-authenticated, but in some cases Windows erroneously chooses public. Check the category of the network where your clients are located using the following command:
PS > Get-NetConnectionProfile
If the network category needs to be changed from public to private, run the following command:
PS > Set-NetConnectionProfile -InterfaceIndex <interface index> -NetworkCategory Private
A script that is not a part of Windows is used in this step. Never blindly trust scripts you download. Either make sure that the source can really be trusted, or inspect the script to ensure that it will not harm your system before using it.
Windows includes a cmdlet with which you can create self-signed certificates, but unfortunately certificates that can be used for WinRM authentication cannot be generated. Luckily there is a PowerShell script available that can generate usable certificates.
The (9/11/2016 version of the) script is also included in this
manual so you can download it directly using, for example, wget or Invoke-WebRequest. The site above presents a license agreement which prevents direct downloads.
Check that the script has not been modified by checking its signature. The second command shows more detailed information about how the script is signed:
PS > Get-AuthenticodeSignature New-SelfSignedCertificateEx.ps1 PS > Get-AuthenticodeSignature New-SelfSignedCertificateEx.ps1 | Format-List *
Make sure that you verify the certificate subject (CN=Sysadmins LV IK, O=Sysadmins LV IK, L=Riga, C=LV) and
thumbprint (1A8EAB5B0611AC0548F16A1675B8A3915CC2045E) before actually running the
script on the server.
First import the function in the script file, and then create the certificate for the server using the function.
The common name (CN) of the subject needs to match the name that you will use to connect to the server later. If you
want to use the simple hostname, you can use $env:COMPUTERNAME. The documentation of
the script says that friendly names can be used to specify the enhanced key usage, but this does not seem to work
everywhere. So the OID for server
authentication is used here instead:
PS > . .\New-SelfSignedCertificateEx.ps1 PS > $serverCert = New-SelfSignedCertificateEx -Subject "CN=<(fully-qualified) hostname>" -EnhancedKeyUsage '1.3.6.1.5.5.7.3.1' -StoreLocation LocalMachine -IsCA $true
The certificate has been added to Cert:\LocalMachine\My\ (the certificates identifying
the server machine) and Cert:\LocalMachine\CA\ (certificate authorities (CAs) that are
trusted on the server machine), using the thumbprint as the child name.
The thumbprint is going to be needed to verify whether the correct public key has been downloaded by clients, so display it and copy it somewhere:
PS > $serverCert
The final step for the Windows server is the addition of a secure WinRM listener. This is done in two steps: creation of the listener and opening of the firewall for it.
Execute the following command to create the listener. The hostname must match the hostname used when creating the server certificate:
PS > winrm create WinRM/Config/Listener?Address=*+Transport=HTTPS "@{Hostname=`"<(fully-qualified) hostname>`";CertificateThumbprint=`"$($serverCert.ThumbPrint)`"}"
Next open the firewall for the port (5986). The port is only opened on domain and private networks. If you want WinRM to be available on public networks too, omit profile='domain,private':
PS > netsh advfirewall firewall add rule name='WinRM-HTTPS' dir=in localport=5986 protocol=TCP profile='domain,private' action=allow
And that is it for the server configuration. We will return to the server when a local administrator for client connections has to be created. But that is part of the client configuration chapters.