Versions Compared

Old Version 7

changes.mady.by.user Shinken Trainee

Saved on

compared with

New Version 8

changes.mady.by.user Shinken Trainee

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue
Panel
titleSommaire

Table of Contents
stylenone

Contexte

Afin de superviser une machine Windows, le pack windows-by-WinRM propose un modèle d'hôte :

  • windows-by-WinRM permet la supervision d'un linux pour une vérification des fonctions principales ( CPU, disques, RAM, interfaces réseaux ... ).
  • windows-by-WinRM__extra qui permet une supervision plus personnalisée de l'hôte ( Surveillance de fichiers ).


Info

Afin de s'adapter à vos besoins précis, il est possible de directement modifier les modèles suivants :

  • windows-by-WinRM
  • windows-by-WinRM__extra

Ceux-ci héritent des modèles suivants :

  • windows-by-WinRM__shinken
  • windows-by-WinRM__extra__shinken

Ils contiennent toute la logique du pack.

  • Vous ne devez pas modifier ces modèles internes ( finissant par la particule '__shinken' ).
    • Vos modifications seront potentiellement écrasées lors de la prochaine mises à jour du pack.

Liste des modèles d'hôte pour windows-by-WinRM__shinken

NomLien
No Format
windows-by-WinRM
NEW-PAGE - SPAC-27 - Modèle windows-by-WinRM
No Format
windows-by-WinRM__extra
NEW-PAGE - SPAC-27 - Modèle windows-by-WinRM__extra

Modes d'authentification

Le pack windows-by-winrm__shinken offre les modes d'authentifications suivants :

  • basic
  • gss-negotiate

basic

L'authentification basic utilise un nom d'utilisateur et un mot de passe. Ces derniers sont envoyés en clair sur le réseau, l'ensemble des échanges ne sont pas chiffrés.

Afin de protéger ces échanges réseaux clair, il est possible d'utiliser HTTPS pour chiffrer la communication.

negotiate

negotiate n'est pas un mode d'authentification, mais un protocole de négociation de support d'authentification.

Le polleur et l'hôte supervisée vont se mettre d'accord en entamant une connexion sur quelle méthode d'authentification choisir.
En premier lieu Kerberos va être priorisé car il est plus sécurisé, puis si cela échoue NTLM sera utilisé.

NTLM

NTLM nécessite un nom d'utilisateur et un mot de passe. NTLM est activé par défaut sur votre serveur windows.

Ce protocole n'est plus recommandé par Microsoft depuis 2010, et une faille critique permetant permettant de craquer les hashs des mots de passes observés sur le réseaux réseau a été publié en 2024 ( NTLM V2 ).

NTLM offre une communication un échange d'authentification chiffré.

Note
iconfalse

L'utilisation de NTLM nécessite le packet gssntlmssp sur le poller.

La connexion NTLM échoue sous centos-7.

Kerberos

L'authentification Kerberos nécessite une connection à l'hôte supervisée en utilisant un nom DNS, un domaine Windows, un nom d'utilisateur et un mot de passe.

Ce protocole est recommandé et utilisé par windows par défault depuis windows 2000.

Kerberos offre une communication chiffréchiffrée.