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 WinRMProtocol 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 |
