La supervision Par Nagios/Shinken d’hôtes Windows permet de surveiller la santé ou l’activité de points très précis du système, mais la mise en œuvre tien parfois de la véritable gageure. Une des complications est la gestion des droits WMI sous Windows. En effet, si l’on veut mettre un peu de sécurité (ce qui est indispensable lorsque l’on intervient en entreprise), on évitera soigneusement d’utiliser un compte administrateur du serveur pour réaliser les requêtes WMI. Le problème étant qu’un compte standard (utilisateur simple) ne pourra pas, par défaut, effectuer les requêtes.
On test une requête WMI juste après la création de l’utilisateur WMI-user auquel nous n’avons attribué aucun privilège particulier. Les requêtes WMI peuvent être complexes et longues à taper. Nous avons donc pris une requête courtes. La syntaxe du client WMI wmic est la suivante:
wmic -U user%password //@IP_target "select * from Win32_ComputerSystem"
Voici le message d’erreur affiché cette requête WMI :
ERROR: dcom_creat_object.
ERROR: Login to remote object.
NTSTATUS: NT_STATUS_NET_WRITE_FAULT
Afin de donner les bons privilèges à notre utilisateur WMI, il faut parcourir différents endroits bien cachés dans les recoins sombres de Windows.
Création et gestion de l’utilisateur
Pour commencer, ajouter l’utilisateur au groupe local (ou le groupe de domaine) « Performance Monitor Users ».
Attribuer les permissions DCOM
WMI utilise DCOM pour traiter les appels distants. L’utilisateur doit donc être autorisé à effectuer des appels distants via DCOM. Pour configurer les permissions, ouvrir « Service de composants » situé dans les outils d’administration, ou lancer directement la commande DCOMCNFG.
Développer le nœud « Services de composants \ Ordinateurs » puis afficher les propriétés de « Poste de travail ».
Dans la nouvelle fenêtre, sélectionner l’onglet « Sécurité COM » puis cliquer sur le bouton « Modifier les limites… » dans le cadre « Autorisation d’exécution et d’activation ».
Ajouter l’utilisateur et lui affecter les permissions adéquates.
Si l’on essai à nouveau la commande depuis le serveur de supervision, elle se termine toujours par une erreur. Néanmoins les symptômes ont changés, comme on peut le voir ci dessous :
L’erreur DCOM n’apparait plus. A la place, une erreur 0x0041003 , et l’erreur et bien longue à s’afficher qu’au premier essai. Cela tend à prouver que l’appel distant via DCOM est maintenant autorisé. Le problème vient maintenant de la requête WMI qui n’est pas autorisées pour cet utilisateur.
Attribuer les permissions WMI
Afin d’accéder à la console de gestion WMI, lancer la commande wmimgmt.msc (dans le menu Exécuter, par exemple). On obtient la console ci-dessous :
Faire un clic droit sur “WMI Control (Local)” puis propriété. Sélectionner l’onglet « Sécurité » dans la nouvelle fenêtre.
Tous les espaces de noms (namespaces) connus du système sont répertoriés dans cette fenêtre, et il est possible de gérer la sécurité pour chacun d’eux. Le plus couramment utilisé étant CIMV2, le sélectionner puis cliquer sur le bouton Securité.
Ajouter l’utilisateur (user-WMI dans mon cas) puis sélectionner les actions qu’il sera autorisé à exécuter. Celles-ci peuvent être :
| Level | Description |
| Execute Methods | Allows methods exported from the WMI classes or instances to be run. |
| Full Write | Allows full read, write, and delete access to all WMI objects, classes, and instances. |
| Partial Write | Allows write access to static WMI objects. |
| Provider Write | Allows write access to objects that are provided by providers. |
| Enable Account | Allows read access to WMI objects. |
| Remote Enable | Allows remote access to the namespace. |
| Read Security | Allows read-only access to WMI security information. |
| Edit Security | Allows read and write access to WMI security information. |
Les options minimum à autoriser pour les requêtes fonctionnent avec l’utilisateur sont :
– Execute Methods
– Enable Account
– Remote Enable
On relance la requête WMI depuis le serveur, le résultat de la requête doit être affiché.
