Objectives of this documentation
This documentation is intended for any user wishing to use ServiceNav checks based on the WinRM protocol.
Why use WinRM?
WinRM is the protocol for remote management of 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 monitor and this protocol is not blocked by antivirus.
It is therefore preferable to use it compared to the Winexe approach.
Verify that WinRM is installed on the monitored server
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 WinRMProtocol enabled :

Protocol not activated :

Enabling 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 "Remote Windows Management (HTTP-Enter)" firewall rules are enabled.

Configuring SNB for Kerberos authentication
To connect to the target machine, SNB makes a Kerberos ticket request to Active Directory and then uses it to connect to the server to be monitored.
For this ticket request to work, you have to configure the /etc/krb5.conf file present on the SNB.
As root on SNB, edit the file /etc/krb5.conf :
vim /etc/krb5.conf
The file must be configured in this way (change only the framed values) :

Box in red: fill in the customer's complete domain in CAPITAL LETTERS.
Green box: fill in the DNS name of the Active Directory server in CAPITAL LETTERS.
Box in blue: fill in the complete client domain in lowercase.
Careful: don't forget to put the dot in front of 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 SNB, run the command :
kinit @
Then enter the user's password.

If no mistake was made, the Kerberos ticket will have been 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 SNB
From 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' -a 'krb' -d 'ipconfig' -t 'cmd' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb' -a 'krb

Above, the connection to the target server works and returns the result of the "ipconfig" command.
If the above tests work, all ServiceNav checks that use WinRM will be able to run correctly.
Causes of possible errors
kinit: Preauthentication failed while getting initial credentials

Authentication problem (user or password) when obtaining the Kerberos ticket.
What to do?
Check the login, domain and 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 entered in the /etc/krb5.conf file 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 file
What to do?
Correct the "kdc" and "admin_server" values in the /etc/krb5.conf file (green box above).
During the connection test : 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 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.
During the connection test: Connection to timed out

The connection test does not work when WinRM is enabled on the target server.
What to do ?
On the server, check that the firewall rules " Remote Windows Management (HTTP-Entry) are enabled.

During the connection test : « Server not found in Kerberos database »

DNS registration problem.
What to do ?
Kerberos is based on the DNS protocol.
The target machine must have an a PTR record.
From the box, check that the nslookup tests are working:

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 log in remotely, it is necessary to be part of the Administrators group (or Remote Management Users for Windows 2012 and higher) either by logging in directly with the correct account (for example via a domain administrator user) or by authenticating as an administrator via the parameter Credential.
On Windows 2012 and higher, it is necessary to add a registry key on the remote computer for the Administrators and Remote Management Users groups to be able to log in via Remote Powershell :
In the node: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem
You have to 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 log on via WinRM to the target machine, the user must be part of the "Local Administrator" group of the target machine.
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384295v=vs.85.aspx |