Documentations

Configurer WinRM pour interroger un équipement windows

Sur la page

Besoin d'aide ?

Objectifs de cette documentation

Cette documentation est destinée à tout utilisateur souhaitant utiliser les points de contrôle ServiceNav basés sur le protocole WinRM.

Pourquoi utiliser WinRM ?

WinRM est le protocole de gestion à distance des serveurs Windows. Il permet de se connecter sur les machines et d’exécuter des commandes PowerShell.
Il a pour avantage d’être nativement supporté par tous les équipements Windows. Il n’y a donc rien à installer en plus sur les serveurs à superviser et ce protocole n’est pas bloqué par les antivirus.
Il est donc préférable de l’utiliser par rapport au service Winexe.

Vérifier que WinRM est installé sur le serveur à superviser

Par défaut le service WinRM est démarré sur les versions Windows suivantes :

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

Se connecter sur le serveur à superviser, ouvrir une console PowerShell et lancer la commande : 

Get-Service WinRM

Protocole activé :

Protocole non activé :

Activer WinRM sur un serveur Windows

Sur le serveur Windows cible, ouvrir une console PowerShell en Administrateur.

Lancer la commande :

Enable-PSRemoting

S’assurer que les règles de pare-feu « Gestion à distance de Windows (HTTP-Entrée) soient bien activées.

Configuration de la SNB pour authentification Kerberos

Pour se connecter à la machine cible, la SNB réalise une demande de ticket Kerberos à l’Active Directory puis l’utilise pour se connecter sur le serveur à superviser.

Pour que cette demande de ticket fonctionne, il faut configurer le fichier /etc/krb5.conf présent sur la SNB.

En root sur la SNB, éditer le fichier /etc/krb5.conf :

vim /etc/krb5.conf

Le fichier doit être configuré de cette manière (ne modifier que les valeurs encadrées) :

Encadré en rouge : renseigner le domaine complet du client en MAJUSCULE.

Encadré en vert : renseigner le nom DNS du serveur Active Directory en MAJUSCULE.

Encadré en bleu : renseigner le domaine complet du client en minuscule.
Attention : ne pas oublier de mettre le point devant le nom de domaine comme dans le premier encadré bleu !

Tester le fonctionnement de WinRM depuis la SNB

Obtention d’un ticket Kerberos auprès de l’Active Directory

Depuis la SNB, lancer la commande :

kinit <user>@<CLIENT.DOMAIN.FR>

Puis entrer le mot de passe de l’utilisateur.

Si pas d’erreur, le ticket Kerberos a pu être obtenu.

Vérifier ensuite la présence et la validité du ticket Kerberos avec la commande :

klist

On peut voir la date d’obtention du ticket, sa date d’expiration et le domaine pour lequel il est valide.

Tester la connexion sur un serveur Windows via WinRM depuis la SNB

Depuis la SNB, lancer la commande :

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

Ci-dessus, la connexion sur le serveur cible fonctionne et renvoie le résultat de la commande « ipconfig ».

Si les tests ci-dessus fonctionnent, tous les points de contrôle ServiceNav qui utilisent WinRM pourront s’exécuter correctement.

Cas d’erreurs possibles

kinit: Preauthentication failed while getting initial credentials

Problème d’authentification (utilisateur ou mot de passe) lors de l’obtention du ticket Kerberos.

Que faire ?

Vérifier le login, le domaine et le mot de passe utilisé.

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

Erreur de nom de domaine.

Que faire ?

  • Vérifier que le domaine renseigné dans la commande « kinit » soit correct.
  • Vérifier que le noms de domaine renseignés dans le fichier /etc/krb5.conf soient corrects (encadrés rouge et bleu).

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

Serveur Active Directory incorrect dans le fichier /etc/krb5.conf

Que faire ?

Corriger les valeurs « kdc » et « admin_server » dans le fichier /etc/krb5.conf (encadré en vert ci-dessus).

Lors du test de connexion : Failed to establish a new connection: [Errno 111] Connection refused

WinRM n’est pas activé sur le serveur cible ou le port WinRM n’est pas ouvert entre la SNB et le serveur cible.

Que faire ?

  • Activer WinRM sur le serveur cible.
  • Vérifier que le port TCP/5985 soit ouvert entre la SNB et le serveur cible.

Lors du test de connexion : Connection to <IPaddress> timed out

Le test de connexion ne fonctionne pas alors que WinRM est bien activé sur le serveur cible.

Que faire ?

Sur le serveur, vérifier que les règles de pare-feu « Gestion à distance de Windows (HTTP-Entrée) soient bien activées.

Lors du test de connexion : « Server not found in Kerberos database »

Problème d’enregistrement DNS.

Que faire ?

Kerberos se base sur le protocole DNS.
La machine cible doit posséder un Enregistrement A et un Enregistrment PTR.

Depuis la box, vérifier que les tests nslookup fonctionnent :

Si erreur « ** server can’t find myServer: SERVFAIL » alors l’enregistrement DNS n’est pas correct.

ET

Si erreur « ** server can’t find 5.15168.192.in-addr.arpa: NXDOMAIN » alors l’enregistrement DNS PTR n’est pas correct.

Droits d’utilisation WinRM

Afin de se connecter à distance, il est nécessaire de faire partie du groupe Administrators (ou Remote Management Users pour Windows 2012 et supérieur) soit en étant connecté directement avec le bon compte (par exemple via un utilisateur administrateur du domaine) soit en s’authentifiant en tant qu’administrateur via le paramètre Credential.

Sur Windows 2012 et supérieur, il est nécessaire d’ajouter une clé de registre sur l’ordinateur distant pour que les groupes Administrators et Remote Management Users aient le droit de se connecter via Remote Powershell :

Dans le nœud : HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem

Il faut ajouter la clé DWord : LocalAccountTokenFilterPolicy avec la valeur 1.

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

Afin de pouvoir se connecter via WinRM à la machine cible, l’utilisateur doit faire partie du groupe « Administrateur local » de la machine cible.

 

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

Ceci pourrait aussi vous intéresser

2 – Comment superviser un environnement Azure

3 – Superviser les métriques Azure via les API

1 – Prérequis plugins Azure et Office 365

fr_FR
en_US fr_FR

Bienvenue sur ServiceNav !

Vous avez besoin d’aide ? Plus d’informations sur nos produits ? Ecrivez-nous !
Vous avez pris connaissance de notre politique de confidentialité.

[COVID - 19 ] – TÉLÉTRAVAIL, OBJECTIF DISPONIBILITÉ 100% !

Pendant la durée de l'épidémie, assurez la disponibilité et la performance de vos services IT de télétravail, avec ServiceNav !

Suite à l’appel du gouvernement à la mobilisation pour aider les entreprises à surmonter le contexte sanitaire et économique actuel, nous vous aidons gratuitement à assurer la surveillance complète de vos environnements de télétravail : VPN, VDI, Teams, Skype Entreprise, Citrix… Objectifs : collecte, indicateurs de disponibilité et d’utilisation, tableaux de bord pour appuyer votre communication.
Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.

Réservez votre place

Vous avez pris connaissance de notre politique de confidentialité.