Vérification de la connectivité de l'outil de découverte à vCenter Résolution des problèmes liés à WinRM Résolution des problèmes liés à Kerberos Résolution des problèmes liés aux bases de Résolution des problèmes SNMP Erreurs de collecte sur le réseau Erreurs de collecte des métriques du système d'exploitation Problèmes d'accès dans l'inventaire découvert Résolution des problèmes liés à l'authentification par clé SSH Résolution des problèmes d'installation Linux Messages d'erreur courants

Résolution des problèmes

Vérification de la connectivité de l'outil de découverte à vCenter

Lorsque vous rencontrez des erreurs de configuration du module VMware, procédez comme suit pour vérifier la connectivité :

Accédez à la machine virtuelle de l'outil de découverte

Log-in vers la machine virtuelle de l'outil de découverte, ouvrez la console distante dans vCenter
- Nom d'utilisateur : discovery
- Mot de passe : mot de passe

Testez la connectivité vCenter

Testez l'accès à l'API vCenter :


curl -v --insecure -u <username>:<password> https://<vcenter-ip-or-hostname>:443/mob

Résultat de réussite attendu :


[ec2-user@discoverytool ~]$ curl -v --insecure -u <user>:<password> https://vcsa/mob > tmp.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.2.125:443...
* Connected to vcsa (192.168.2.125) port 443 (#0)
...
</xml>
* Connection #0 to host vcsa left intact

Tester le certificat SSL

Exécutez cette commande :


openssl s_client -showcerts -servername <hostname> -connect <hostname>:443

Résultat de réussite attendu :

Devrait afficher les détails du certificat vSphere
Vérifie la SSL/TLS connectivité sur le port 443


[ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443
CONNECTED(00000003)
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = vcsa.onpremsim.env, C = US
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=vcsa.onpremsim.env/C=US
   i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=vcsa.onpremsim.env/C=US
issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering
---

Résolution des problèmes liés à WinRM

Si vous rencontrez des problèmes de connectivité avec WinRM, procédez comme suit pour tester la connexion. Ces étapes s'appliquent également aux problèmes de Hyper-V connectivité, car l'outil de découverte utilise WinRM pour communiquer avec Hyper-V les hôtes.

Testez la connectivité WinRM de base à l'aide des ports 5985 (HTTP) et 5986 (HTTPS). Nous devons nous assurer que la connectivité fonctionne sur le port 5986 (HTTPS)


# Check WinRM listener configuration
winrm enumerate winrm/config/listener

# Note: Replace <HOST> with the target computer's hostname or IP address. Adjust the username and password as needed. 
# Test WinRM connection on port 5985 (HTTP)
$cred = Get-Credential
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5985

# Test WinRM connection on port 5986 (HTTPS)
Test-WSMan -Computer <HOST> -Authentication Negotiate -Credential $cred -Port 5986

Si les tests ci-dessus échouent, essayez d'établir une PowerShell session avec la validation des certificats désactivée :


$cred = Get-Credential
$so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
Enter-PSSession -ComputerName <HOST> -Credential $cred -Port 5985 -SessionOption $so

Résolution des problèmes liés à Kerberos

Si vous rencontrez des échecs d'authentification Kerberos lors de la collecte de données à partir de serveurs Windows, consultez les sections suivantes pour diagnostiquer et résoudre les problèmes courants.

Vérifiez les exigences du réseau

Avant de résoudre les problèmes d'authentification Kerberos, vérifiez que l'outil de découverte peut atteindre les points de terminaison réseau requis.

Pour vérifier la configuration réseau requise pour Kerberos

Vérifiez la résolution DNS auprès du contrôleur de domaine. Exécutez la commande suivante depuis la machine virtuelle de l'outil de découverte :
```
nslookup dc01.example.com
```
Vous pouvez également utiliser dig :
```
dig dc01.example.com
```
Si la résolution DNS échoue, vérifiez que la machine virtuelle de l'outil de découverte est configurée pour utiliser un serveur DNS capable de résoudre votre domaine Active Directory. Vérifiez /etc/resolv.conf et confirmez que les entrées du serveur de noms pointent vers les serveurs DNS de votre domaine.
Vérifiez la connectivité au centre de distribution de clés (KDC) sur le port 88. Exécutez la commande suivante :
```
nc -zv dc01.example.com 88
```
Sortie attendue :
```
Connection to dc01.example.com 88 port [tcp/kerberos] succeeded!
```
Si la connexion échoue, vérifiez qu'aucune règle de pare-feu ne bloque le trafic entre la machine virtuelle de l'outil de découverte et le contrôleur de domaine sur le port 88.
Vérifiez la connectivité aux serveurs Windows cibles sur les ports WinRM. Exécutez les commandes suivantes :
```
nc -zv <windows-server> 5985
nc -zv <windows-server> 5986
```
Si la connexion échoue, vérifiez que WinRM est activé sur le serveur cible et que les règles de pare-feu autorisent le trafic entrant sur les ports 5985 et 5986.

Problèmes courants liés à Kerberos

Vous trouverez ci-dessous des problèmes courants liés à Kerberos et leurs solutions.

Erreurs de distinction majuscules/

Symptôme : Vous recevez le message d'erreur « Serveur introuvable dans la base de données Kerberos » lors de l'authentification.

Cette erreur se produit généralement lorsque le nom de domaine Kerberos n'est pas en majuscules. Les domaines Kerberos doivent être spécifiés en majuscules dans votre fichier. krb5.conf Par exemple, utilisez EXAMPLE.COM plutôt que example.com.

Prévention du verrouillage des comptes

L'outil de découverte utilise un mécanisme de temporisation pour empêcher le verrouillage des comptes suite à des tentatives d'authentification infructueuses répétées. Si votre compte de service est verrouillé, vous pouvez réinitialiser le processus de collecte en arrêtant puis en démarrant le module de collecte via l'interface utilisateur Web de l'outil de découverte à l'adressehttps://<discovery-tool-vm-ip>:5000.

kinit échoue à partir de la CLI

Le tableau suivant répertorie les kinit erreurs courantes et leurs solutions.

Erreur	Cause	Solution
Impossible de trouver le KDC pour le domaine	Le nom d'hôte ou l'adresse IP du KDC ne sont pas accessibles, ou le domaine n'est pas configuré dans. `krb5.conf`	Vérifiez que le `krb5.conf` fichier contient le nom d'hôte et le domaine KDC corrects. Vérifiez la résolution DNS et la connectivité réseau au KDC sur le port 88.
Échec de la préauthentification	Le mot de passe du compte de service est incorrect.	Vérifiez le mot de passe et réessayez. Si le compte est verrouillé, déverrouillez-le dans Active Directory avant de réessayer.
Client introuvable dans la base de données Kerberos	Le nom principal ne correspond à aucun compte dans Active Directory.	Vérifiez que le nom principal correspond exactement au nom du compte, majuscule comprise. Utilisez le format `username@REALM` avec le domaine en majuscules.
Impossible de résoudre l'adresse réseau du KDC	Le DNS ne peut pas résoudre le nom d'hôte du KDC.	Vérifiez la configuration DNS dans`/etc/resolv.conf`. Vérifiez que le serveur DNS peut résoudre le nom d'hôte du KDC. Testez avec `nslookup` ou`dig`.

La collecte échoue malgré un kinit réussi

En cas de kinit succès mais que la collecte de données échoue toujours, vérifiez les points suivants :

Vérifiez que le nom principal utilisé pour la collecte correspond kinit exactement au dossier utilisé pendant la collecte.
Vérifiez que le compte de service dispose des autorisations requises sur les serveurs cibles.
Vérifiez que WinRM est activé sur les serveurs cibles.
Vérifiez que le nom d'hôte utilisé pour la collecte correspond au nom d'hôte enregistré dans Active Directory.

Kerberos fonctionne pour certains serveurs mais pas pour d'autres

Si l'authentification Kerberos réussit pour certains serveurs mais échoue pour d'autres, examinez les points suivants :

Si vos serveurs couvrent plusieurs domaines Active Directory, configurez des informations d'identification Kerberos distinctes pour chaque domaine. Assurez-vous que votre /etc/krb5.conf fichier inclut des entrées pour tous les domaines. Chaque domaine nécessite ses propres informations d'identification avec le username@REALM principal approprié.

Comparez la configuration WinRM sur un serveur en fonctionnement avec celle d'un serveur défaillant. Exécutez la commande suivante sur chaque serveur :


winrm get winrm/config

Testez la connectivité avec Remote Desktop pour isoler le problème. L'outil de découverte utilise le formatusername@DOMAIN, tandis que Remote Desktop utilise le formatDOMAIN\username.

Vérifiez que le compte de service est membre du groupe d'administrateurs local sur le serveur défaillant. Exécutez la commande suivante sur le serveur cible :


net localgroup Administrators

WMI a besoin de privilèges d'administrateur local pour accéder aux informations du système d'exploitation. La collecte SQL Server nécessite également que le compte de service dispose d'un accès administrateur local sur le serveur cible.

Liste de contrôle de configuration de Kerberos

Utilisez la liste de contrôle suivante pour vérifier votre configuration Kerberos avant de commencer la collecte de données.

Le krb5.conf fichier existe sur la machine virtuelle de l'outil de découverte.
Le nom du domaine est en majuscules dans. krb5.conf
L'exécution kinit avec le compte de service réussit sans erreur.
Running klist montre un billet valide et non expiré.
Le nom principal correspond exactement au nom du compte Active Directory.
La résolution DNS fonctionne pour le nom d'hôte du KDC.
La connectivité réseau au KDC sur le port 88 est confirmée.
La connectivité réseau vers les serveurs Windows cibles sur les ports 5985 et 5986 est confirmée.
(Multi-domain) Chaque domaine Active Directory possède ses propres informations d'identification configurées dans l'outil de découverte [realms] et krb5.conf contient des [domain_realm] entrées pour tous les domaines.

Résolution des problèmes liés aux bases de

Pour diagnostiquer les problèmes de collecte de la base de données Oracle, tels que des données manquantes ou des erreurs, vérifiez les points suivants.

Connexion refusée ou expiration du délai

Symptôme : L'état de la collection Oracle indique une erreur de connexion pour un serveur.

Pour résoudre ce problème, vérifiez les points suivants :

Vérifiez que le récepteur Oracle est en cours d'exécution sur l'hôte cible : lsnrctl status
Vérifiez la connectivité réseau entre l'outil de découverte et l'hôte Oracle sur le port 1521 (ou sur votre port personnalisé) : nc -zv <oracle-host> 1521
Vérifiez que les règles de pare-feu autorisent les connexions entrantes sur le port du récepteur Oracle.
Vérifiez le nom du service en l'exécutant lsnrctl services sur l'hôte Oracle. Si le nom du service est incorrect, le récepteur Oracle rejette la connexion.

Défaillances d'authentification (ORA-01017)

Symptôme : La collecte échoue en raison d'une erreur de nom d'utilisateur ou de mot de passe non valide.

Pour résoudre ce problème, vérifiez les points suivants :

Vérifiez que le compte de service Oracle existe et qu'il n'est pas verrouillé : SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';
Vérifiez que le mot de passe est correct en vous connectant manuellement : sqlplus discovery_user/<password>@<host>:1521/<service_name>
Si le compte est verrouillé, déverrouillez-le : ALTER USER discovery_user ACCOUNT UNLOCK;

Privilèges insuffisants (ORA-01031)

Symptôme : la connexion réussit mais la collecte renvoie des données incomplètes.

Pour résoudre ce problème, vérifiez les points suivants :

Vérifiez que SELECT_CATALOG_ROLE est accordé : SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';
Accordez le rôle requis s'il manque : GRANT SELECT_CATALOG_ROLE TO discovery_user;

Les informations d'identification manuelles indiquent une erreur mais la connexion automatique fonctionne

Lorsque vous épinglez manuellement un identifiant à un serveur, l'outil de découverte ne revient pas en cas d'échec de la connexion. Vérifiez que le port et le nom du service que vous avez configurés sur les informations d'identification correspondent à ceux du récepteur Oracle sur ce serveur spécifique. Si le serveur possède un port ou un nom de service non standard, mettez à jour la configuration des informations d'identification en conséquence.

OS-level solution de repli ne détectant pas Oracle

Si aucune information d'identification de base de données n'est configurée et que la OS-level solution de secours ne détecte pas Oracle :

Vérifiez que les informations d'identification du système d'exploitation SSH ou WinRM sont configurées et fonctionnent pour le serveur (vérifiez l'état de la collecte des métriques du système d'exploitation).
Pour les hôtes Linux, vérifiez qu'ils /etc/oratab existent ou que les processus Oracle Process Monitor (pmon) sont en cours d'exécution.
Pour les hôtes Windows, vérifiez que les entrées de registre Oracle existent HKLM\SOFTWARE\Oracle ou que oracle.exe les processus sont en cours d'exécution.

Résolution des problèmes SNMP

Accédez à la machine virtuelle de l'outil de découverte

Log-in vers la machine virtuelle de l'outil de découverte, ouvrez la console distante dans vCenter
- Nom d'utilisateur : discovery
- Mot de passe : mot de passe

Installez les outils SNMP (si nécessaire)

sudo yum install net-snmp-utils -y

Tester la connexion SNMP aux serveurs Linux

snmptable -v 2c -c <COMMUNITY_STRING> <REMOTE_SERVER_IP> .1.3.6.1.2.1.6.13.1

Exemple :


#SNMPv2c:
snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with authentication):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

#SNMPv3 (with privacy):
snmptable -v 3 -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> 192.168.1.100 .1.3.6.1.2.1.6.13.1

Erreurs de collecte sur le réseau

un terminal est nécessaire pour lire le mot de passe

Erreur :


ss command failed on <host>: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required

La commande ss demande le mot de passe utilisateur. L'utilisateur ssh configuré doit appartenir au groupe sudoers et être configuré avec sudo sans mot de passe pour la commande. ss/netstat Pour configurer le sudo sans mot de passe :

Créez un nouveau fichier sudoers :
```
sudo vi -f /etc/sudoers.d/<username>
```

Ajoutez la ligne :


<username> ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat

Après cette modification, en cours d'exécution sudo ss -tnap et sudo netstat -tnap devrait s'exécuter sans demander de mot de passe

La collecte réseau s'est exécutée sans sudo

Si l'avertissement suivant s'affiche sur la page Inventaire découvert :


Network collection ran without sudo. Process-level connection data may be missing.

Cet avertissement indique que le compte utilisateur SSH ne dispose pas d'un accès sudo sur le serveur cible. Sans sudo, l'outil de découverte peut toujours collecter des données de connexion réseau, mais il ne peut pas déterminer à quel processus appartient chaque connexion. Pour collecter des données de connexion complètes au niveau du processus, assurez-vous que l'utilisateur SSH dispose d'un accès sudo sur le serveur cible.

Erreurs de collecte des métriques du système d'exploitation

UUID de serveur manquant pour les serveurs Linux

Si l'outil de découverte ne parvient pas à collecter l'UUID du serveur (affiché comme vide ou manquant) pour les serveurs Linux, vérifiez que les informations d'identification SSH configurées pour ces serveurs disposent de privilèges sudo. L'outil permet dmidecode de lire l'UUID du serveur. S'il n'dmidecodeest pas installé, l'outil revient à la lecture/sys/class/dmi/id/product_uuid, qui nécessite également un accès sudo. Sans sudo, aucune méthode ne peut récupérer l'UUID.

Solution : Assurez-vous que le compte utilisateur SSH fourni à l'outil de découverte dispose d'un accès sudo sur les serveurs Linux cibles.

Problèmes d'accès dans l'inventaire découvert

Si vous voyez un message dans l'état de la collecte du serveur, tel que Informations d'identification manquantes ou Accès refusé :

Sélectionnez le serveur dans le tableau des serveurs découverts.
Choisissez Gérer les informations d'accès Vous pouvez choisir de :
1. Sélectionnez d'autres informations d'identification dans le menu déroulant Sélectionner les informations d'identification.
2. Sélectionnez Utiliser de nouvelles informations d'identification et fournir de nouvelles informations d'identification.
Enregistrez.

L'outil de découverte tente à nouveau de se connecter une fois que vous avez enregistré vos modifications.

Résolution des problèmes liés à l'authentification par clé SSH

Test de la connectivité par clé SSH à partir de l'outil de découverte

Si l'authentification par clé SSH échoue, vérifiez la connectivité entre l'outil de découverte et le serveur cible :

Connectez-vous à l'outil de découverte (via la console vSphere ou SSH sur l'hôte Linux).

Testez la connectivité SSH à l'aide de votre clé privée :


ssh -i /path/to/private_key -o StrictHostKeyChecking=no <username>@<target_ip>

Si la connexion réussit, le problème réside dans la manière dont la clé a été téléchargée dans l'outil de découverte. Re-upload la clé et vérifiez que le nom d'utilisateur correspond.
Si la connexion échoue, consultez le message d'erreur dans le tableau suivant.

Message d’erreur	Cause	Résolution
`Permission denied (publickey)`	La clé publique ne se trouve pas dans le `authorized_keys` fichier du serveur cible ou le nom d'utilisateur est incorrect.	Ajoutez la clé publique `~/.ssh/authorized_keys` sur le serveur cible pour le bon utilisateur. Vérifiez les autorisations des fichiers :`chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys`.
`Connection timed out after 20s`	Le port 22 n'est pas accessible depuis l'outil de découverte.	Vérifiez que le port 22 est ouvert entre l'outil de découverte et le serveur cible. Vérifiez les pare-feux et les groupes de sécurité.
`Connection refused`	Le service SSH n'est pas en cours d'exécution sur le serveur cible.	Démarrez le service SSH :`sudo systemctl start sshd`.
`Invalid SSH key for credential 'name'`	Le format de clé n'est pas pris en charge, les données clés sont endommagées ou le mot de passe est manquant ou incorrect.	Vérifiez que le format de clé est RSA, ECDSA ou Ed25519 au format PEM, OpenSSH ou PKCS #8. Si la clé est cryptée, assurez-vous que le mot de passe est correct.

Résolution des problèmes d'installation Linux

Le port 5000 est déjà utilisé

Symptôme : Le service de l'outil de découverte ne démarre pas après l'installation.

Résolution : Identifiez et arrêtez le processus à l'aide du port 5000 :


sudo ss -tlnp | grep :5000

Arrêtez le processus conflictuel, puis redémarrez l'outil de découverte :


sudo ./AWS-Transform-discovery-tool.sh start

Messages d'erreur courants

Ce tableau décrit les messages d'erreur courants et leurs explications :

Message	Location	Explication
Un mot de passe a déjà été créé	Créer une page de mot de passe	Condition de course lorsque deux utilisateurs créent des mots de passe en même temps ; actualiser
Échec de l'exportation	Page d'inventaire	Réessayer ou envoyer les journaux
Une collecte à la demande est déjà en cours	Page d'inventaire	Condition de course lorsque deux utilisateurs démarrent des collectes manuelles en même temps ; réessayez une fois la collecte manuelle en cours terminée
`Command timed out after 60s`	État de la collecte du serveur	Une commande sur le serveur cible n'a pas été exécutée dans les 60 secondes. Cela peut se produire sur des serveurs très chargés. Réessayez la collecte ou examinez la charge du serveur cible.
Une ou plusieurs informations d'identification contiennent des UUID inconnus	Page d'accès au système d'exploitation	Condition de course lorsque deux utilisateurs modifient les informations d'identification du système d'exploitation en même temps ; réessayez
Mot de passe non valide	Sign-in page	Mot de passe incorrect pour la connexion ; contactez l'administrateur ou contactez
Votre session a expiré. Veuillez vous reconnecter.	Sign-in page	La session a expiré, vous devez vous reconnecter
Une erreur interne s'est produite	Pages diverses	Réessayer ou envoyer les journaux

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Considérations sur la sécurité

Notes de mise à jour