Documentations

Configuring WinRM to query a Windows device

On the page

Do you need help?

Objectives of this documentation

This documentation is intended for any user wishing to use WinRM-based ServiceNav checkpoints.

Why use WinRM?

WinRM is the remote management protocol for Windows servers. It allows you to connect to the machines and execute PowerShell commands.
It has the advantage of being natively supported by all Windows devices. There is therefore nothing to install on the servers to be supervised and this protocol is not blocked by antivirus software.
It is therefore preferable to use it compared to the Winexe service.

Check that WinRM is installed on the server to be monitored

By default the WinRM service is started on the following Windows versions:

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

Connect to the server to be monitored, open a PowerShell console and run the command : 

Get-Service WinRM

Protocol enabled :

Protocol not activated :

Enable WinRM on a Windows server

On the target Windows server, open a PowerShell console as Administrator.

Run the command :

Enable-PSRemoting

Make sure that the "Windows Remote Management (HTTP-Entry)" firewall rules are enabled.

Configuring SNB for Kerberos authentication

To connect to the target machine, the SNB makes a Kerberos ticket request to the Active Directory and then uses it to connect to the server to be monitored.

For this ticket request to work, the /etc/krb5.conf file on the SNB must be configured.

As root on the SNB, edit the file /etc/krb5.conf :

vim /etc/krb5.conf

The file should be configured as follows (only change the boxed values):

Box in red: fill in the client's complete domain in UPPERCASE.

Green box: fill in the DNS name of the Active Directory server in UPPERCASE.

Box in blue: fill in the complete client area in tiny.
Warning: remember to focus before the domain name as in the first blue box!

Test the operation of WinRM from SNB

Obtaining a Kerberos ticket from the Active Directory

From the SNB, run the command :

kinit @

Then enter the user's password.

If no error, the Kerberos ticket could be obtained.

Then check the presence and validity of the Kerberos ticket with the command :

klist

You can see the date the ticket was obtained, its expiration date and the domain for which it is valid.

Test the connection on a Windows server via WinRM from the SNB

From the SNB, run the command :

/usr/local/nagios/libexec/winrm_command.py -H '@IP_target' -l 'CLIENT.DOMAIN.EN/user' -x 'password' -c 'ipconfig' -t 'cmd' -a 'krb

Above, the connection on the target server is working and returns the result of the "ipconfig" command.

If the above tests work, all ServiceNav checkpoints that use WinRM will be able to run correctly.

Possible cases of error

kinit: Preauthentication failed while getting initial credentials

Authentication problem (user or password) when obtaining the Kerberos ticket.

What to do?

Check the login, the domain and the password used.

kinit: Cannot find KDC for realm "DOMAIN" while getting initial credentials

Domain name error.

What to do?

  • Check that the domain entered in the "kinit" command is correct.
  • Check that the domain names in /etc/krb5.conf are correct (red and blue boxes).

kinit: Cannot contact any KDC for realm 'user@DOMAIN' while getting initial credentials

Incorrect Active Directory server in /etc/krb5.conf

What to do?

Correct the "kdc" and "admin_server" values in /etc/krb5.conf (green box above).

When testing the connection: Failed to establish a new connection: [Errno 111] Connection refused

WinRM is not enabled on the target server or the WinRM port is not open between the SNB and the target server.

What to do?

  • Enable WinRM on the target server.
  • Check that the TCP/5985 port is open between the SNB and the target server.

When testing the connection: Connection to timed out

The connection test does not work even though WinRM is enabled on the target server.

What to do?

On the server, check that the "Windows Remote Management (HTTP-In)" firewall rules are enabled.

During the connection test: "Server not found in Kerberos database

DNS record problem.

What to do?

Kerberos is based on the DNS protocol.
The target machine must have an A and a PTR record.

From the box, check that the nslookup tests work:

If error "** server can't find myServer: SERVFAIL" then the DNS record is not correct.

AND

If error "** server can't find 5.15168.192.in-addr.arpa: NXDOMAIN" then the DNS PTR record is not correct.

WinRM user rights

In order to connect remotely, it is necessary to be part of the Administrators group (or Remote Management Users for Windows 2012 and higher) either by being connected directly with the right account (e.g. via a domain administrator user) or by authenticating as an administrator via the Credential.

On Windows 2012 and above, it is necessary to add a registry key on the remote computer for the Administrators and Remote Management Users groups to have the right to connect via Remote Powershell :

In the : HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem

You must add the key DWord : LocalAccountTokenFilterPolicy with the value 1.

Source : https://blog.piservices.fr/post/2013/10/30/Powershell-Gestion-a-distance

In order to be able to connect via WinRM to the target machine, the user must be a member of the "Local Administrator" group of the target machine.

 

Référence : https://msdn.microsoft.com/en-us/library/windows/desktop/aa384295%28v=vs.85%29.aspx

You may also be interested in

How to monitor an Azure environment

Monitor Azure metrics via APIs

azure portal

Azure and Office 365 plugins requirements

en_GB

Welcome to ServiceNav!

Do you need some help? More information about our products? Write to us!
You have taken note of our privacy policy.
We use cookies to ensure the best experience on our site. If you continue to use this site, we will assume that you are satisfied with it.

Reserve your place

You have taken note of our privacy policy.