How to force WinRM to listen interfaces over HTTPS
Windows Remote Management (WinRM) is a protocol for Windows operating systems which is implemented as a web service and is used for secure remote management of systems. Following actions depends on WinRM configuration;
- Windows Remote Shell command line tool
- Winrs
- Event Forwarding
- Windows PowerShell 2.0 Remoting
WinRM service starts automatically on Windows Server 2008 but by default no listener for WinRM is configured. That means no WS-Management protocol message can be received or sent.
Default ports for WinRM 2.0 are;
HTTP: 5985
HTTPS: 5986
For those who are interested in PowerShell scripting, PowerShell remoting is a great and helpful feature which comes with 2.0 version. PsRemoting provides to execute powershell scripts on remote computers over WinRM protocol. Even you are in your local PowerShell console, you can run any scripts and these will be executed on remote computers. And each remote connection resides in a session that you can manage separately.
But be aware of that if you want to get some actions on a operating system that uses WinRM, you must configure required prerequirements. In this blog post we’ll cover how to configure WinRM to work over HTTPS. So that for example you can execute your powershell scripts on remote computers over HTTPS with certificate based authentication. This will also help you to configure mutual authentication between untrusted computers that uses WinRM for communication.
For basic configuration, simply run WinRM qc(quickconfig) command.
This is a shortcut to configure winrm to work over http. Running this command takes following actions;
- Creating a WinRM listener on https://* for local networks.
- Enabling firewall exceptions for WinRM
After you configure with QuickConfig command you can enumerate listener status;
As you see above, it listens over HTTP and for all network interfaces. But what we want is to configure HTTPS communication.
HTTPS communication requires certificate based authentication. For Windows Remote Management, each computer that will be managed with WinRM must have a Server Authentication certificate.
Most important point is that certificate must have a subject name same with computer netbios name(workgroup) or FQDN(domain joined). You can use Web Server Template in your certificate templates store. My suggestion is just duplicate your web server certificate and configure it as its private key exportable.
Now let’s request a certificate from local Certification Authority step by step.
Type your local CA URL in your browser and click Request a certificate.
Click advanced certificate request.
Choose your custom Server Authentication template and fill up the fields.
Don’t forget to set Name field same as your computer name. If it’s a domain joined computer, type your fully qualified domain name. Otherwise netbios name will be enough.
When you click Install Certificate on your browser, certificate will be sent to Current User account store. We should export it with private key and then import to the computer account store again.
Check your certificate Subject name if it matches with your computer name.
To configure WinRM over HTTPS we need Server Authentication certificate thumbprint.
Just open your certificate that you import earlier and note thumbprint details.
Now we can run following winrm command to create winrm listener and configure it to work with previously created certificate.
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="serverfqdn";CertificateThumbprint="1fd53031caf98df226428069ccfdf3152b6ddc2b"}
Check for the ResourceCreated output.
Now lets enumerate listener again;
As you see above, listener sends and receives messages over HTTPS.
From now on, WinRM connections will be active.
If you try to start Remote PowerShell session between two computer that uses certificate based WinRM, you will notice that it opens and listens connections over port 5986.
As I mentioned before this method also can be used between a domain joined computer and workgroup computer. And please note that, If you don’t configure required authentication method, WinrM first tries to communicate over Kerberos.