Une GPO ne permet pas d’installer nativement le service SNMP sur Windows : elle sert avant tout à configurer SNMP une fois la fonctionnalité présente sur les postes ou serveurs. L’installation, elle, passe généralement par PowerShell, un script de démarrage déployé en GPO, ou un outil de déploiement logiciel. Ce guide détaille les trois étapes indispensables : installer le service, pousser sa configuration par stratégie de groupe, puis vérifier que tout fonctionne correctement.
Pourquoi distinguer installation et configuration SNMP
Le protocole SNMP (Simple Network Management Protocol) n’est pas activé par défaut sous Windows. Il s’agit d’une fonctionnalité facultative à ajouter avant de pouvoir la piloter via une stratégie de groupe. Confondre les deux étapes est l’erreur la plus fréquente des administrateurs qui découvrent ce déploiement : une GPO appliquée sur un poste sans le service SNMP installé n’aura strictement aucun effet visible.
Sur Windows Server, l’ajout se fait via la fonctionnalité « SNMP Service » du gestionnaire de serveur ou en PowerShell. Sur Windows 10 et Windows 11, SNMP est traité comme une fonctionnalité à la demande (capability), avec une cmdlet différente. Cette distinction entre les deux familles de systèmes conditionne toute la suite du déploiement.
Installer le service SNMP avec PowerShell
Sur Windows Server
La cmdlet à utiliser est Install-WindowsFeature (ou Add-WindowsFeature sur les versions plus anciennes) :
Install-WindowsFeature -Name SNMP-Service -IncludeManagementTools
Cette commande installe le service SNMP ainsi que les outils de gestion associés. Elle peut être intégrée dans un script de provisioning ou exécutée à distance sur plusieurs serveurs via Invoke-Command.
Sur Windows 10 et Windows 11
Le service SNMP est ici une fonctionnalité à la demande, installée avec :
Add-WindowsCapability -Online -Name "SNMP.Client~~~~0.0.1.0"
Le nom exact de la capability peut légèrement varier selon la build Windows ; il est recommandé de vérifier son intitulé exact avec Get-WindowsCapability -Online | Where-Object Name -like "SNMP*" avant de lancer l’installation en masse.
Déployer l’installation à grande échelle
Pour un parc de postes, trois méthodes coexistent :
- un script PowerShell exécuté via une GPO en tant que tâche planifiée ou script de démarrage,
- un outil de déploiement logiciel (SCCM, Intune, ou équivalent),
- une exécution à distance via PowerShell Remoting sur une liste de machines.
La GPO seule ne déclenche pas cette installation : elle peut au mieux exécuter un script qui, lui, effectue réellement l’installation.
Vérifier l’installation avant de poursuivre
Avant de passer à la configuration, confirmez que le service est bien présent sur chaque machine ciblée. Sur Windows Server, une simple vérification suffit :
Get-WindowsFeature -Name SNMP-Service
Sur Windows 10/11, la commande équivalente est :
Get-WindowsCapability -Online -Name "SNMP.Client~~~~0.0.1.0"
Un état « Installed » confirme que la GPO de configuration pourra désormais s’appliquer utilement. Sauter cette étape de vérification est une source fréquente de confusion : on pousse une configuration GPO qui semble sans effet, alors que le service lui-même n’existe simplement pas encore sur le poste.
Configurer SNMP via GPO
Une fois le service installé sur les machines cibles, la configuration proprement dite peut être poussée par stratégie de groupe. Les paramètres se trouvent dans :
Configuration ordinateur > Modèles d’administration > Réseau > Service SNMP
Trois réglages principaux y sont disponibles :
Communautés SNMP autorisées : définit les chaînes de communauté acceptées par l’agent, avec un niveau de droit associé. Il est fortement déconseillé d’utiliser les valeurs par défaut public ou private, trop souvent ciblées par des scans automatisés. Privilégiez une chaîne personnalisée et complexe.
Hôtes autorisés à envoyer des requêtes SNMP (managers autorisés) : restreint les adresses IP habilitées à interroger l’agent. Seules les IP des serveurs de supervision doivent y figurer.
Destinations des interruptions (traps) : à configurer uniquement si des alertes SNMP doivent être envoyées vers un collecteur.
Les clés de registre correspondantes
Si vous préférez une approche par préférences de stratégie de groupe (registre) plutôt que par modèles d’administration, ces réglages sont stockés sous les clés suivantes :
ValidCommunities: liste des communautés SNMP acceptées et leur niveau de droit.PermittedManagers: liste des adresses IP autorisées à interroger l’agent.TrapConfiguration: destinations des traps SNMP, si utilisées.
Ces clés se situent sous HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters. Les pousser via une préférence GPO permet un contrôle plus fin, notamment quand les modèles d’administration ne couvrent pas un besoin spécifique.
Droits en lecture seule par défaut
Sauf besoin explicite d’écriture (rare en supervision classique), configurez toujours la communauté en READ ONLY. Cela limite fortement les risques en cas de compromission de la chaîne de communauté.
Sécuriser le déploiement dès la conception
SNMP v1 et v2c, les versions les plus répandues sous Windows, transmettent la communauté en clair sur le réseau. Cette limitation historique du protocole impose une vigilance particulière au moment de la configuration GPO :
- ne jamais réutiliser une communauté déjà connue ou devinée sur un autre équipement du réseau,
- limiter strictement la liste des managers autorisés aux seules IP de supervision, sans plage large « pour simplifier »,
- désactiver l’écriture SNMP tant qu’aucun besoin métier ne la justifie,
- documenter la communauté utilisée dans un gestionnaire de secrets plutôt que dans un script en clair,
- envisager SNMPv3 si l’environnement de supervision le permet, ce protocole apportant authentification et chiffrement, contrairement à v1/v2c.
Ces précautions évitent qu’un service ouvert pour la supervision ne devienne une porte d’entrée exploitable sur le réseau interne.
Activer le service et ouvrir le pare-feu
La configuration GPO ne suffit pas si le service n’est pas démarré ou si le trafic est bloqué.
Démarrage automatique du service
Une GPO de préférence (ou un script complémentaire) doit forcer le service SNMP en démarrage automatique et s’assurer qu’il est bien lancé :
Set-Service -Name SNMP -StartupType Automatic
Start-Service -Name SNMP
Règle de pare-feu
SNMP utilise le port UDP 161 pour les requêtes classiques. Si des traps sont utilisées, le port UDP 162 doit également être ouvert, en sens entrant sur le collecteur de supervision. Une règle de pare-feu Windows peut être poussée via GPO :
New-NetFirewallRule -DisplayName "SNMP UDP 161" -Direction Inbound -Protocol UDP -LocalPort 161 -Action Allow
Limitez idéalement cette règle aux adresses IP des serveurs de supervision plutôt qu’à l’ensemble du réseau.
Organiser les GPO par périmètre d’application
Un déploiement SNMP ne concerne généralement pas l’ensemble du parc, mais un sous-ensemble précis : serveurs applicatifs, équipements réseau gérés par Windows, ou postes d’un service technique particulier. Il est recommandé de créer une GPO dédiée, liée uniquement à l’unité d’organisation (OU) contenant ces machines, plutôt que de modifier une GPO globale déjà existante.
Cette approche présente plusieurs avantages concrets : elle facilite l’audit (une seule GPO à consulter pour connaître tout le périmètre SNMP), elle limite les effets de bord sur des machines qui n’ont pas besoin de ce service, et elle permet de retirer la configuration proprement en supprimant simplement la liaison de la GPO, sans devoir démêler des paramètres mélangés à d’autres réglages réseau.
Pensez également à filtrer la GPO par groupe de sécurité si le périmètre ne correspond pas exactement à une OU existante. Le filtrage par sécurité, combiné à un filtre WMI ciblant la version de Windows le cas échéant, permet d’appliquer la configuration uniquement là où elle a du sens, en particulier dans un environnement mixte associant Windows Server et postes clients.
Tableau récapitulatif du déploiement
| Élément | Méthode recommandée | Remarque |
|---|---|---|
| Installation SNMP | PowerShell / script GPO | GPO seule n’installe pas le service |
| Configuration SNMP | GPO (modèles ou registre) | Communauté, managers, droits |
| Pare-feu | GPO (règle entrante) | UDP 161, UDP 162 si traps |
Vérifier que la configuration fonctionne
Une fois les GPO déployées, forcez leur application avant tout test :
gpupdate /force
Un redémarrage du poste ou du service peut être nécessaire selon le type de paramètre modifié. Vérifiez ensuite l’état du service via services.msc ou Get-Service SNMP, puis testez la réponse de l’agent depuis le serveur de supervision avec un outil comme snmpwalk ou directement depuis votre solution de monitoring (Centreon, PRTG, Zabbix, etc.).
Un test réussi confirme trois choses simultanément : le service est installé et démarré, la GPO de configuration a bien été appliquée, et le pare-feu laisse passer le trafic SNMP depuis l’IP de supervision.
Dépannage : SNMP ne répond pas après la GPO
Plusieurs causes reviennent régulièrement lorsque l’agent SNMP reste muet après un déploiement GPO :
Service non installé : la GPO configure un service absent. Vérifiez avec Get-Service SNMP que le service existe bien sur la machine.
GPO non appliquée : utilisez gpresult /r pour confirmer que la stratégie a bien été reçue par le poste, et forcez une actualisation avec gpupdate /force.
Pare-feu bloquant : le port UDP 161 (ou 162 pour les traps) n’est pas ouvert, ou la règle ne cible pas le bon profil réseau (domaine, privé, public).
Communauté incorrecte : la chaîne de communauté configurée côté agent ne correspond pas à celle utilisée par l’outil de supervision.
Manager non autorisé : l’adresse IP du serveur de supervision n’a pas été ajoutée à la liste des hôtes autorisés à interroger l’agent.
SNMP sous Windows : un protocole legacy encore utile en supervision
SNMP reste une technologie ancienne, et certaines organisations lui préfèrent désormais des agents de supervision plus modernes. Il demeure cependant largement répandu dans les environnements de supervision réseau existants, notamment pour interroger des équipements hétérogènes avec un protocole standardisé. Un déploiement propre, en lecture seule, avec une communauté personnalisée et des managers strictement limités, reste une solution fiable et peu coûteuse à maintenir pour la supervision d’un parc Windows Server ou de postes clients. 🛠️
