End-to-end management of WinRM HTTP for PowerShell

Most organizations make heavy use of PowerShell, but it is much less common to see its remote management features deployed. It is even less common to see remote management secured using HTTPS.

There are many good resources available for the implementation of WinRM over HTTPS, but no good resources for maintaining the WinRM listener’s health, and updating the machine certificate used by the listener once the initial certificate expires or is revoked.  This can prove to present quite a challenge.

Customer Evidence

When one of our Enterprise Financial customers wanted to go-live with end-to-end encryption for all management traffic, they were dismayed to find no turnkey solution to this issue.  To this Fortune 100 Firm, security and protection of customer data is of the utmost importance, and thus the need for full HTTPS when using PowerShell Remoting to comply with Security and Industry standards, and prevent passwords and important information from being communicated in the clear.   Already an ivision Platinum Customer of our Engineering and Support Services, they turn to their ivision Partners to help create one.  

Two of our engineers, Bradley Milbauer and Stephen Owen were tasked to complete this project and over the course of two weeks created a full solution to handle all aspects of provisioning, validating and maintaining WinRM Security.

ivision is proud to share the fruits of one of our recent engagements with the public and Open Source community.  

ivision WinRM Maintenance Script

We have developed a PowerShell script that will streamline the provisioning of WinRM, make sure the HTTPS listener exists and is healthy, and make sure the best machine authentication certificate is being used.

Why this PowerShell Script is Needed

Microsoft doesn’t provide a GPO or other mechanism to automatically configure WinRM over HTTPs. Most turn to scripting to enable these listeners. However, once the HTTPS listener is enabled, WinRM never checks again to see if the cert is still valid, and certs expire. So, if you’re able to provision WinRM over HTTPs throughout your environment, you’ll then be challenged to develop your own mechanism to handle updating certs too. Not fun.

What it does

This single script handles all of these problems. Here’s how we handle each of the following scenarios:

• Don’t HTTPS configured today? We’ll check for a certificate, and if we find one, we’ll configure the listeners and throw an exit code 0.
• Already have everything configured perfectly? We throw an exit code 0.
• You don’t have a certificate available for HTTPS? We’ll throw an exit code 1 which you can catch using SCCM or LanDesk to remediate.
• Have HTTPS but it’s using an old cert? We’ll resolve the records for the new longest available cert and will update your machines HTTPs listener.

Requirements for WinRM over HTTPs

• Client operating system version must be Windows Vista SP1 or later.
• Server operating system version must be Windows Server 2008 or later.
• A PKI implementation based on Active Directory Certificate Services must already be in place, with an existing workflow to provision machines with certificates. This blog post also assumes machine authentication certificates have been deployed to your computers.
• PowerShell 4.0 or greater on client and server machines.

Download link

The script can be found here.  Send us a Pull Request if you’d like to Contribute!  

Want help with something different?

ivision has extensive experience implementing PKI, working with PowerShell, securing servers, and with systems management in general. If you’re interested in leveraging ivision for systems management projects like this one, please give us a shout and we’ll be happy to talk with you!