Configuring WinRM to access a Windows host

On the page

Need some help?

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 WinRM

Protocol enabled :

Protocol not activated :

Enabling WinRM on a Windows server

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

Run the command :


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 :


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/ -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.


If error "** server can't find 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.


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.



This may also be of interest to you

How to monitor an Azure environment

Monitor Azure metrics via APIs

portal azure

1 - Prerequisites Azure and Office 365 plugins


Welcome to ServiceNav!

Need help? More information about our products? Write to us!
You have taken note of our privacy policy.


While the epidemic lasts, ensure the availability and performance of your IT services for teleworking, with ServiceNav!

Following the government's call to mobilize to help businesses overcome the current health and economic context, we help you, free of charge, to ensure the complete monitoring of your teleworking environments: VPN, VDI, Teams, Skype Enterprise, Citrix... Objectives: collection, availability and usage indicators, dashboards to support your communication.
We use cookies to ensure that you have the best possible experience on our site, and 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.