I really like using WinRM (Windows Remote Management) to manage my servers and lab. It serves as the basis for server management that Microsoft is moving in to. It provides several advantages:
- It is secured by default by leveraging strong encryption to protect traffic.
- It is standards based so it allows for interoperability with other platforms.
- it is SOAP based making it firewall friendly and easier to route in segmented enviromentes.
- I can leverage Kerberos for authentication.
- It allows me to query WMI information from the host without the need of opening RPC ports or dealing with DCOM it self.
One of the problems with WinRM is that by being compatible it provides downgrading of its security for compitibility or user error. In Windows one can disable encryption when connecting and also specify Basic for auth exposing credentials. In a Windows only environment one could set it up to enforce encryption and force stronger authentication methods but we hardly see that kind of enviroment often that is why I prefer SSL when possible. To protect me from user naivate and have already a foundation for future integrations.
In this example we will use the Active Directory Certificate Role on a Windows 2012 R2 server so as to be able to deploy certificates using Group Policy Objects. Sames steps will work on Windows 2008 R2 and Windows 2012.
We start by openting the Certificate Authority management console, Right-Clicking on Certificate Templates and selecting Manage
It will open a template management console. we will scroll down and select WebServer template and Right-Click on it selecting Duplicate Template
In the certificate property window for the new template we navigate to the General Tab and set a Display Name and Template Name. I recommend using the same and with no spaces. Had once a weird bug where on Windows 2008 it would enroll a new certificate again and again if a space was in the display name.
In the Subject Name tab select in Subject name format select Common Name and click on the checkbox of DNS name.
Add the group that you want to be able to request code signing certificates and the Domain Computers Group for the domain. Allow Read and Enroll, Click on Apply and then Ok. For Auto enrollment select the domain computers and enable Read, Enrolll and Autoenroll.
Here is an animation of the cloning and setup of the certificate for machine auto enrollment only.
How to make the template available:
To auto enroll the computer on the domain or OUs we want we need to create a GPO we can link to these containers. We open the Group Policy Management console and create a new GPO
Provide a descriptive name for the policy
Once created select the policy, right-click on it and select Edit
In the Group Policy Object Select Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies and select and enter in to the properties of Certificate Services Client - Auto-Enrollment
et the Configuration Model to Enable and select the options to auto renew and to update the certificate if changes as it fits your policies.
You can now link the GPO and wait for the GPO update to happen on the hosts this can take up to 2 hours or you can use the PowerShell to force a Policy update as described in this post http://www.darkoperator.com/blog/2015/3/9/updating-group-policy-objects-remotely
Once the client enroll you should be able to see the issued certificates in the Certificate Authority management console.
One can now enable WinRM to use HTTPS. Sadly Microsoft does not provide a way to enable HTTPS using GPO. This command can be placed in a logon script to enable WinRM and make it use only HTTPS on the hosts.
winrm quickconfig -transport:https