NetWorker : le compte de connexion vCenter se verrouille après des échecs de connexion répétés

Après avoir modifié le mot de passe du compte de connexion NetWorker vCenter, plusieurs événements d’échec de connexion se produisent et le compte de connexion vCenter est verrouillé à plusieurs reprises.

Après avoir effectué les étapes suivantes, le compte continue de verrouiller :
1. Mettez à jour le mot de passe du vCenter dans VMware View.
2. Effacer tout InventorySessions.gob (s’ils existent) à partir de :

3. Redémarrez toutes les appliances vProxy.

NetWorker effectue des appels d’API (Application Programming Interface) vers le port 443 de vCenter à l’aide du mécanisme d’authentification de base. L'« authentification de base » est effectuée à l’aide des informations d’identification stockées dans la ressource NSR Hypervisor. Les informations d’identification ne sont ni stockées ni traitées ailleurs dans la solution NetWorker VMware Protection (NVP).

Si les opérations suivantes sont effectuées avec succès dans NetWorker, il n’est pas possible que les informations d’identification soient incorrectes dans NetWorker.

• NetWorker Management Console (NMC) VMware View Refresh fonctionne.
• NetWorker Web User Interface (NWUI) L’actualisation de VMware vCenter fonctionne
• Il n’y a pas d’inventaire (nsrvim) liées à des erreurs dans le fichier daemon.raw:
  • Linux : /nsr/logs/daemon.raw
  • Windows (par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw
  • NetWorker : Utilisation de nsr_render_log pour afficher .raw fichiers journaux
• Les opérations NetWorker VMware Protection (sauvegarde, restauration) réussissent.

Si quelque chose d’externe verrouille le même compte que celui utilisé par NetWorker, les opérations ci-dessus commencent à échouer. Il est peu probable que les informations d’identification deviennent soudainement incorrectes dans NetWorker, sauf si :

• Un utilisateur met à jour le NSR Hypervisor ressource doit contenir des informations d’identification incorrectes. Vérifiez le journal RAP sur le NetWorker Server :
  • Linux : /nsr/logs/rap.log
  • Windows (par défaut) : C:\Program Files\EMC NetWorker\nsr\logs\rap.log

02/27/2026 02:22:55 PM MONITOR_RAP: cn=Backup Admin,ou=Dell,dc=amer,dc=lan@nsr.amer.lan CHANGED 'NSR hypervisor' resource, vcsa.amer.lan:
                    password: *******;
                    password: *******;

• La commande NSR Hypervisor utilise un compte vSphere Single Sign-On (SSO), un utilisateur a mis à jour les informations d’identification des comptes SSO dans VMware ; Les informations d’identification dans NetWorker ne sont donc plus correctes.
• La commande NSR Hypervisor La ressource utilise un compte externe. Cette configuration nécessite des configurations d’autorité externe dans vSphere. NetWorker effectue l'« authentification de base » auprès du vCenter à l’aide du compte externe. Le vCenter gère la demande d’authentification entre le serveur vCenter et le fournisseur d’autorité externe (par exemple, Microsoft AD).

si NSR Hypervisor est un compte d’authentification externe (AD/LDAP). Consultez les administrateurs VMware et de domaine. NetWorker effectue une « authentification de base » sur le vCenter. L’authentification de domaine/externe se produit en dehors de NetWorker, entre le vCenter Server et l’autorité externe.

Pour écarter NetWorker, il est recommandé de configurer temporairement NetWorker pour qu’il utilise un autre compte SSO vCenter. Idéalement, le compte doit être un compte SSO vSphere afin d’exclure les problèmes potentiels entre vCenter et le fournisseur d’authentification externe (AD/LDAP).
Si possible, utilisez le compte administrator@vsphere.local ou un autre compte SSO local disposant des autorisations requises. Les autorisations requises par NetWorker sont documentées dans le Guide d’intégration de NetWorker VMware. La documentation NetWorker est disponible ici : Prise en charge de NetWorker | Manuels et documents 

Si le compte n’est plus défini sur aucun NetWorker Server et qu’il continue d’être verrouillé, un autre élément entraîne le verrouillage du compte.

Cela doit être examiné dans VMware. 

• La journalisation vCenter VPXD affiche les tentatives d’authentification, mais ces demandes s’affichent en tant que 127.0.0.1 et non le système d’où provient la demande d’authentification.
• Les logs vCenter SSO enregistrent les échecs, mais n’incluent pas l’adresse IP du client. Cela signifie qu’il n’est pas possible de confirmer si la demande provient de NetWorker. Vous voyez uniquement l’utilisateur, le client et le résultat. 
• vCenter rhttpproxy ou les logs front-end enregistrent l’adresse IP source du client pour les demandes d’API/HTTPS entrantes qui atteignent le front-end de vCenter. Sur les appliances VCSA modernes, cela peut être géré par le front-end Envoy plutôt que par l’environnement existant rhttpproxy mais le principe est le même : Le journal de bord est l’endroit où l’adresse IP du client est visible.

Vérifiez également auprès de votre réseau ou de votre équipe de sécurité si d’autres systèmes contactent régulièrement le vCenter sur le port 443. 
Un autre outil de sauvegarde ou de création de rapports peut utiliser le même compte et être à l’origine du verrouillage.