WinRM is Microsoft's implementation of WS-Management in Windows which allows systems to access or exchange management information across a common network. Utilizing scripting objects or the built-in command-line tool, WinRM can be used with any remote computers that may have baseboard management controllers to acquire data. Windows-based computers including WinRM certain data supplied by Windows Management Instrumentation can also be obtained.
Components
WinRM Scripting API
* Provides an Application programming interface enabling scripts to remotely acquire data from computers that perform WS-Management operations.
* Provides hardware management and facilitates control of remote server hardware through BMCs. IPMI is most useful when the operating system is not running or deployed as it allows for continued remote operations of the bare metal hardware/software.
WMI plug-in
* Allows WMI data to be made available to WinRM clients.
WMI service
* Leverages the WMI plug-in to provide requested data or control and can also be used to acquire data from most WMI classes. Examples include the Win32_Process, in addition to any IPMI-supplied data.
WS-Management protocol
* Web Services Management is a DMTFopen standard defining a SOAP-based protocol for the management of servers, devices, applications and various Web services. WS-Management provides a common way for systems to access and exchange management information across the IT infrastructure.
Common uses
communicates with Windows servers over WinRM using the pythonpywinrm package and can remotely run PowerShell scripts and commands. Thycotic's Secret Server also leverages WinRM to enable PowerShell remoting. SolarWinds Server and Application Monitoring software utilizes a WinRM server on monitored servers for its PowerShell integration. CloudBolt leverages WinRM as part of Blueprints, Server Actions, and CB Plugins to execute remote scripts on Windows servers using the python module.
Security
WinRM uses Kerberos for initial authentication by default. This ensures that actual credentials are never sent in client-server communications, instead relying on features such as hashing and tickets to connect. Although WinRM listeners can be configured to encrypt all communications using HTTPS, with the use of Kerberos, even if unencrypted HTTP is used, all communication is still encrypted using a symmetric 256-bit key after the authentication phase completes. Using HTTPS with WinRM allows for additional security by ensuring server identity via SSL/TLS certificates thereby preventing an attacker from impersonating it.
