WinRM | It's kind of a like / hate thing...

  • Article

Sure, I like WinRM.

It enables remote management of Windows over HTTP and it is at the core of how we perform configuration and change automation here in MSIT.  When configured properly it makes execution of tasks on remote machines insanely simple and without it I don't think we'd be able to perform half of the activities we have automated in SMA and Azure Automation Workflow runbooks.

The problem is that it has to be enabled and properly configured - out of the box you aren't going to find it very useful unless you've already configured via custom images, group policy or the like.  This is where the side of the equation opposite to like comes into play.

Even if you are enabling WinRM at build time, at data center scale you are bound to come across machines that are not going to play nice and will break your automation and bring dishonor to your family.  So lets look at what to configure and how we can test for and remediate problem at runtime.

Enable WinRM and configure it to allow remote access:
1.) I'm sure we all know this already: On the remote machine, execute the following from an elevated cmd prompt:   'winrm quickconfig /force'.   This will enable the service and create an http listener endpoint for you.

^ But what if you cannot run the command on the machine w/o if WinRM isn't enabled?   No need to hate - there's a simple trick we use in our automation that includes psexec and a new scheduled task that I'll write up in a separate post real soon.

Need to access network resources from within your WinRM session?  
Lets say that in your SMA or Azure Automation runbooks you need to install or execute software from the network within a remote session or PowerShell Workflow InlineScript.
You'll need to enable CredSSP on your runbook workers so that the remote machine can act as a credential delegate and pass specified creds along to anything on the network you need to authenticate against.

To allow the use of CredSSP perform the following on the client (the machine you are remoting from:)
1.) Execute the following from an elevated PS cmd prompt:  'Enable-WSManCredSSP -DelegateComputer localhost -Role client -Force'
2.) Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with a 'wsman/*' SPN.

 

[caption id="attachment_135" align="alignnone" width="672"]Delegate Fresh Creds Delegate Fresh Creds[/caption]

 

Cool, now you'll be able to authenticate against and access resources on the network over a 'third hop' from the machine you are remoting into.

To force the use of CredSSP in your connections, simply use the authentication and credential parameters with your InlineScript block or new PoSh session:

 

[caption id="attachment_145" align="alignnone" width="654"]Demo InlineScript with CredSSP Demo InlineScript with CredSSP[/caption]

or....

[caption id="attachment_155" align="alignnone" width="884"]PS Session with CredSSP PS Session with CredSSP[/caption]