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