Dépannage de la découverte

Moteur sans agent

Inventaire distant sans agent

Les informations d'inventaire sans agent sont collectées en copiant certains fichiers temporaires sur le périphérique distant. Cela nécessite des références d'authentification Administrateur sur la cible pour l'authentification.

Dépannage : Connectez-vous au périphérique de représentant sans agent et essayez d'accéder au partage Admin de la cible via un chemin UNC :

Exemple : \\10.1.2.3\c$

Si cette connexion affiche une invite d'authentification, essayez de vous authentifier avec les mêmes références d'authentification que celles spécifiées pour le moteur sans agent.

SNMP

Il existe dans le dossier Diagnostics du dossier UNO.DISCOVERY.AGENTLESS.ENGINE64 un outil autonome qui peut servir à tester le bon fonctionnement de SNMP depuis le périphérique sans agent. Cela permet d'exécuter des requêtes ad hoc comme suit :

  1. Lancez une invite de commande Admin.
  2. Utilisez Cd pour accéder à C:\Program Files\Ivanti\Ivanti Cloud Agent\UNO.DISCOVERY.AGENTLESS.ENGINE64\Diagnostics.
  3. Utilisez TestSNMP.exe avec les commutateurs -scanDevice, -ipaddress et -communitystring.
    4. Fenêtre de commande pour testSNMP.exe

Si ces commandes TestSNMP.exe ne renvoient aucune donnée SNMP, le message « Error LIBSNMP_CLASS_TIMEOUT calling SnmpGet » (Erreur LIBSNMP_CLASS_TIMEOUT lors de l'appel à SnmpGet) s'affiche :

Erreurs TestSNMP.exe

Pour les requêtes qui échouent, vérifiez les éléments suivants :

  • Paramètres SNMP sur le périphérique
  • Adresse IP utilisée
  • Chaîne de communauté utilisée
  • Pare-feu/Listes d'accès
  • Routage

Vous pouvez également « explorer » un périphérique pour renvoyer tous les ID d'objet sous un emplacement donné dans la hiérarchie, en utilisant l'option -walkDevice au lieu de
-scanDevice. Pour limiter cette exploration à une branche spécifique de la hiérarchie MIB, spécifiez le point de départ de l'opération walk. Si vous ne spécifiez pas de point de départ, l'arborescence entière est explorée.

Résultats de l'exploration (walk) TestSNMP.exe

Exemple SNMP V3 :

Moteur Discovery (Découverte)

Résolution des noms

Ivanti Neurons for Discovery utilise à la fois NetBIOS et DNS pour tenter de résoudre une adresse IP découverte en un nom. Vous devez activer NetBIOS sur le périphérique découvert et il doit être joignable pour que la requête aboutisse. Pour la résolution des noms DNS, le moteur Discovery connaît uniquement l'adresse IP. Une requête de recherche (lookup) DNS inversée est donc nécessaire pour trouver un enregistrement « ptr » correspondant à l'adresse IP. Cette requête n'est pas exécutée directement sur l'adresse IP découverte. Au lieu de cela, la requête est envoyée à un serveur DNS depuis les paramètres TCP/IP de l'adaptateur préféré.

NetBIOS

À partir du périphérique de découverte, essayez d'utiliser une requête de nom NetBIOS pour résoudre l'adresse IP en nom d'hôte.

Exemple : nbtstat -A 10.38.12.77

En cas de succès, la sortie doit afficher le nom NetBIOS comme dans l'exemple ci-dessous :

Raisons possibles de l'échec :

  • NetBIOS n'est pas activé : Vérifiez les paramètres WINS ou DHCP de l'adaptateur sur le périphérique distant.
  • NetBIOS est bloqué par un pare-feu : Vérifiez le pare-feu du périphérique distant.

DNS

À partir du périphérique de découverte, essayez d'utiliser une requête de recherche DNS inversée pour résoudre l'adresse IP en un nom de domaine entièrement qualifié (FQDN).

Exemple : nslookup 10.38.12.77

En cas de succès, la sortie doit afficher le nom FQDN de la machine, comme dans l'exemple ci-dessous :

Raisons possibles de l'échec :

  • La zone de recherche inversée du serveur DNS pour le sous-réseau n'a pas été créée.
  • Aucun enregistrement n'existe pour le périphérique.

Système d'exploitation

Le système d'exploitation est détecté à l'aide de la technologie d'empreinte d'OS nmap. Elle repose sur les ports TCP et UDP ouverts, pour tenter de prendre l'empreinte du système d'exploitation. Si un pare-feu refuse l'accès aux ports utilisés, la prise d'empreinte peut échouer.

Exemple : Un périphérique Windows 10 porte l'empreinte FreeBSD. Cela peut être dû au fait que le périphérique est verrouillé et que NMAP est incapable de deviner les ports car ils sont bloqués. Cela est généralement dû au fait que le profil de pare-feu local n'autorise pas l'accès pour le partage des fichiers et de l'impression.

Autorisez l'accès de partage des fichiers et des imprimantes pour le profil requis :

Panneau de configuration > Système et sécurité > Pare-feu Windows Defender > Autoriser une appli ou une fonction via le pare-feu Windows Defender :