Contexte

Lorsque vous installez Shinken Enterprise, un certain nombre de modèles et de commandes sont inclus dans votre configuration. 

Le pack "Windows", comme son nom l'indique, permet de superviser des hôtes sur lesquels est installé le système d'exploitation Windows ( serveur ou client ).

Il contient :

• 15 commandes,
• 1 modèle d'hôte,
• 9 modèles de checks.

Les commandes du modèle Windows de notre pack se basent sur le script perl  check_wmi_plus.pl présent dans le répertoire des scripts shinken /var/lib/shinken/libexec ( ou $PLUGINSDIR$ depuis l'Interface de Configuration ).

WMI ( Windows Management Instrumentation ) est un système de gestion interne de Windows qui prend en charge la surveillance et le contrôle de ressources systèmes via un ensemble d’interfaces. Le script perl permet d'interroger ces interfaces via un nom d'utilisateur et un mot de passe. Si l'utilisateur a les droits suffisants, alors le système d'exploitation Windows retournera l'information demandée.

Il utilise le modèle "windows-base" ( voir la page Pack Windows-Base ) pour obtenir 4 données nécessaires pour la connexion à la machine Windows.

Le modèle d'hôte Windows et ses données héritées

Ce modèle contient des données ( locales ) qui seront utilisés par ses checks. Ces données seront utilisées par ses checks et leurs commandes en définissant $_HOST suivi du nom de la donnée.

Si vous souhaitez modifier de manière globale ces données, ou en rajouter, faîtes le directement sur le modèle "windows".

Connexion et arguments de sécurité

La connexion au serveur Windows demande un compte sur le serveur ( local ou compte de domaine ). Plusieurs données permettent de gérer cela :

Fonctionnement WMI sur poste client ou serveur Windows

Windows Management Instrumentation ( infrastructure de gestion Windows )

Le service WMI est installé et démarré par défaut sur les systèmes d'exploitations Windows.

Vous pouvez aller vérifier si ce service est bien démarré en vous rendant dans le gestionnaire de service Windows :

Si vous utilisez des firewall :

• Le Poller doit être autorisé à communiquer avec l'hôte supervisé.
• Les ports WMI de cet hôte doivent être ouverts : les ports TCP 135 et 445 ainsi que des ports dynamiques, typiquement dans le range de 1024 à 1034, doivent être accessibles.

WMI Avancé - gestion de la sécurité

Comme on l'a vu précédemment, les commandes WMI requièrent une authentification au préalable afin de récupérer des informations de supervision sur l'hôte Windows. ( -u "$_HOSTDOMAINUSER$" -p "$_HOSTDOMAINPASSWORD$" )

L'utilisation du compte d'administrateur du poste Windows permet facilement d'obtenir ces informations avec succès, car ce compte à tous les droits d'accès ( WMI, DCOM, etc. ).

Cependant, pour des raisons de sécurité, il se peut que vous préfériez utiliser un compte avec des droits plus restreints.

Voici donc la procédure à suivre pour rajouter des droits à un utilisateur basique qui vous servira à récupérer les informations WMI souhaitées.

Déléguer des droits d'accès minimum d'un utilisateur sur les services Windows

Pour que l'utilisateur puisse avoir les droits de questionner les différents services Windows, il faut au préalable l'autoriser avec des droits de bases. 

Par exemple, il peut être pratique de lister et contrôler uniquement des services clés Windows. Par défaut, les utilisateurs locaux et les comptes non-administrateurs ne possèdent même pas les droits d'agréger les services locaux et encore moins de questionner leurs statuts ou de les redémarrer. Heureusement, il y a un contournement. Il est à noter que cette méthode s'applique pour un compte d'utilisateur, et non pour les groupes de sécurités.

Vous aurez besoin d'un outil spécial appelé "Subinacl" afin de rajouter des permissions, vous pouvez télécharger une copie ici : Microsoft Link.  Attention, il vous faudra un compte Administrateur pour procéder aux étapes suivantes.

La première chose à faire est de déterminer le SID ( identifiant de sécurité ) du compte auquel vous souhaitez ajouter les autorisations. Cela peut être fait de différentes manières, la plus simple étant l'exécution d'une commande wmic :

wmic useraccount where name='utilisateur' get sid

Une fois que vous avez récupéré le SID du compte sur lequel vous souhaitez rajouter les droits, voici les différentes commandes à exécuter :

• Ouvrez une ligne de commande en administrateur et exécuter :

  sc sdshow scmanager

• Copiez l'output (SDDL) et collez le dans un éditeur de texte, ça devrait ressembler à la ligne suivante :

  D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

• Copiez la section entre parenthèses du SDDL incluant le IU ( interactive users ) et collez là juste avant le S:

• Remplacez le 'IU' avec le SID de l'utilisateur, ça devrait ressembler à cela :

  D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CCLCRPRC;;;S-1-5-21-214A909598-1293495619-13Z157935-75714)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

• Exécutez la commande suivante pour autoriser l'utilisateur du SID spécifié à  énumérer les services locaux Windows  :

  sc sdset scmanager "D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CCLCRPRC;;;S-1-5-21-214A909598-1293495619-13Z157935-75714)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"

• Vous aurez besoin de connaitre le “nom court” du service windows sur lequel vous voulez rajouter les permissions, pour obtenir cela depuis le nom complet du service, via la commande suivante :

  sc getkeyname "<Nom complet du Service>"

• Vous pouvez aussi récupérer le nom depuis la MMC de services depuis le panneau de configuration –> Outils d'administration.
  Depuis les propriétés du service souhaité, le "Nom du service" correspond au nom court.
  
  

• Par la suite, l'outil subinacl ( que vous avez précédemment téléchargé et installé ) va permettre de rajouter les permissions de votre compte d'utilisateur sur le service :

  subinacl /verbose /service <nom court du service> /grant=<DOMAINE ou MACHINE>\<compte d'utilisateur>=F

  
  Exemple de rajout des droits sur le service "Pare-feu Windows" pour l'utilisateur MON-PC\USER :

  subinacl /verbose /service MpsSvc /grant=MON-PC\USER=F

  Le “=F” permet d'accorder des permissions totales.

  
  
  

Contrairement à l'utilisation du compte administrateur pour la vérification des services ( qui permet une vue exhaustive et totale ), le rajout des droits d'énumérer les services Windows pour l'utilisateur spécifié ne permet pas de lister et de vérifier la totalité des services.
La commande du pack Windows check_windows_auto_services retournera alors l'état des services ( en démarrage "automatique" ) d'un certain nombre de services Windows et de ceux sur lesquels vous avez rajouté les droits de manière manuelle avec la commande subinacl.

Voici un exemple de commande qui va vérifier un service spécifique, ici la bonne activité du service de "Pare feu" Windows :

$PLUGINSDIR$/check_wmi_plus.pl -H "$HOSTADDRESS$" -u "$_HOSTDOMAINUSER$" -p "$_HOSTDOMAINPASSWORD$" -m checkservice -a MpsSvc -c 0 --inidir=$WMI_INI_DIR$

Résolutions des problèmes

Les checks n'arrivent pas à récupérer les informations alors que l'utilisateur utilisé est Administrateur

Après avoir mis en place le modèle dans Shinken et donné les bons droits à l'utilisateur Windows utilisé par le check, il se peut que les données de performances remontées par les checks ne puissent pas être remontées.

Il est possible dans ce cas que les valeurs de la bibliothèque du compteur de performances Windows soit corrompu ou contienne des valeurs incorrectes.

Dans ce cas, les checks Windows peuvent retourner les erreurs suivantes :

UNKNOWN - The WMI query had problems. The
error text from wmic is: [wmi/wmic.c:212:main()]
ERROR: Retrieve result data.
NTSTATUS: NT code 0x80041017 - NT code
0x80041017

UNKNOWN - The WMI query had problems. The plugin is having trouble finding the required WMI Classes on the target host (172.16.0.132). There can be multiple reasons for this (please go through them and check) including permissions problems (try using an admin login) or software that creates the class is not installed (eg if you are trying to checkiis but IIS is not installed). It can also happen if your version of Windows does not support this check (this might be because the WMI fields are named differently in different Windows versions). Sometimes, some systems 'lose' WMI Classes and you might need to rebuild your WMI repository. Sometimes the WMI service is not running, other times a reboot can fix it. Other causes include mistyping the WMI namesspace/class/fieldnames. There may be other causes as well. You can use wmic from the command line to troubleshoot. Wmic error text on the next line.
[wmi/wmic.c:212:main()] ERROR: Retrieve result data.
NTSTATUS: NT code 0x80041010 - NT code 0x80041010

Il est possible de recréer manuellement les valeurs de la bibliothèque du compteur de Performance avec la commande suivante :

lodctr /r

Plus d'informations sur la commande et ses possibilités peuvent être trouvées sur la page de documentation dédiée: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/lodctr

Erreur : "Error: Can't locate perl58.dll"

Si un script retourne l'erreur :

Error: Can't locate perl58.dll" ou "Error: Can't locate perlXX.dll

Il faut installer/réinstaller ActivePerl

Erreur : "ERROR: Login to remote object."

Si le script retourne l'erreur suivante :

UNKNOWN - The WMI query had problems. The error text from wmic is: [wmi/wmic.c:196:main()] ERROR: Login to remote object.
NTSTATUS: NT code 0x80010111 - NT code 0x80010111

C'est une erreur dû à l'élévation de sécurité  imposée sur les dernières mises à jour de Windows. 

• La mise à jour de Shinken Entreprise avec la dernière version disponible ( elle contient une version des modèles, des checks et de la commande WMIC qui corrige ce problème ).