Analyse de l’état d’une connexion mode sans-agent
L’état d’une connexion mode sans-agent peut être diagnostiquée grâce à la couleur des icônes en forme de bouclier et de calepin :
- Si le bouclier est vert, l’actif enregistré peut être scanné par Cyberwatch
- Si le calepin est vert, Cyberwatch peut déployer des correctifs sur l’actif enregistré
Diagnostiquer les erreurs rencontrées lors de l’ajout d’une connexion mode sans-agent
Ce tableau référence la procédure de résolution des erreurs les plus fréquemment rencontrées lors de l’ajout d’une connexion mode sans-agent.
| Connecteur | Erreur | Résolution |
|---|---|---|
| Tous | getaddrinfo: Name or service not known | L’instance Cyberwatch ne parvient pas à résoudre l’adresse IP associée au nom d’hôte saisie. Dans ce cas, il suffit de configurer les entrées DNS nécessaires à la résolution complète de l’adresse IP et du nom d’hôte de l’actif. |
| WinRM | Connection refused | - Le service WinRM n’est pas activé sur le port 5985 de la machine cible. L’activation de ce service s’effectue en exécutant la commande suivante dans un PowerShell administrateur : Enable-PSRemoting -Force.- La configuration d’un firewall ou d’un équipement tiers bloque le flux entrant venant de Cyberwatch. La commande netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow peut résoudre cela en autorisant les flux WinRM entrant à travers le par feu de la machine cible. |
| WinRM | WinRM::WinRMAuthorizationError | L’utilisateur choisi ne dispose pas des droits nécessaires pour se connecter en WinRM à la cible. Cela concerne par défaut tous les utilisateurs ayant un compte local et non de domaine. L’exécution de la commande suivante dans un PowerShell administrateur y remédie, en activant la clé de registre qui autorise les utilisateurs locaux à faire du WinRM : New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1. |
| SSH | sudo command not found | La connexion ssh entre Cyberwatch et l’actif en question est effective, mais la commande sudo utilisée pour scanner l’actif via les commandes ss et dmidecode n’est pas installée. Son installation solutionne le problème et permet l’analyse complète de l’actif. |
| SSH | could not settle on host_key algorithm | La version des algorithmes d’échange de clé du système à superviser ne sont pas supportées par Cyberwatch. S’il s’agit d’un système d’exploitation supporté, une mise à jour de la version d’openssh suffit. Une version supérieure à openssh 3.9 est requise, mais une version supérieure à 5.7 est recommandée afin de bénéficier d’un niveau de sécurité optimal. |
| SSH | authentication failed | Les identifiants de connexion saisis sont invalides. Il suffit dans ce cas de les modifier afin de renseigner les bons. |
| SSH | Could not identify the operating system (uname:id ...) | Cyberwatch ne parvient pas à identifier le nom de la version d’OS à superviser. Dans ce cas, il est nécessaire de s’assurer que nous supportons cet OS, en se référant à la liste des systèmes d’exploitation supportés. Puis le cas échéant, de nous contacter à support@cyberwatch.fr en nous faisant part de l’erreur rencontrée. |
| SNMP | Timeout after 2 seconds | Ce message peut indiquer une latence réseau, une mauvaise configuration du service SNMP, ou des identifiants mal renseignés. Il convient dans ce cas de relancer le test de connexion en ayant vérifié la configuration SNMP de l’équipement et les identifiants choisis pour s’y connecter. |
| SNMP | No method for Nil::class | Ce message indique que Cyberwatch ne supporte pas le scan cet équipement en SNMP, à l’instar de ceux présents dans cette liste. Dans ce cas, un e-mail peut être adressé à support@cyberwatch.fr, contenant un SNMPWalk complet de l’équipement, afin de permettre une étude d’évolution concernant le support de cet équipement. |