NetWorker: vCenter login account locks after repeated login failure events

After changing the password for Networkers vCenter login account, there are multiple login failure events, and the vCenter login account is repeatedly locked.

After completing the following steps, the account continues to lock:
1. Update the password for the vCenter in VMware View.
2. Clear all InventorySessions.gob (if they exist) files from:

3. Reboot all vProxy appliances.

NetWorker performs Application Programming Interface (API) calls to vCenter port 443 using "basic auth" mechanism. "Basic auth" is performed using the credentials stored in the NSR Hypervisor resource. The credentials are not stored or processed from anywhere else in the NetWorker VMware Protection (NVP) solution.

If the following operations are completed successfully in NetWorker, then it is not possible for the credentials to be incorrect in NetWorker.

• NetWorker Management Console (NMC) VMware View Refresh works.
• NetWorker Web User Interface (NWUI) VMware vCenter Refresh works
• There are no inventory (nsrvim) related errors in the NetWorker server's daemon.raw:
  • Linux: /nsr/logs/daemon.raw
  • Windows (Default): C:\Program Files\EMC NetWorker\nsr\logs\daemon.raw
  • NetWorker: How to use nsr_render_log to render .raw log files
• NetWorker VMware Protection operations (backup, restore) succeed.

If something external is locking the same account that NetWorker is using then the above operations start to fail. It is not likely for the credentials to become suddenly incorrect in NetWorker unless:

• A user updates the NSR Hypervisor resource to contain incorrect credentials. Check the RAP log on the NetWorker server:
  • Linux: /nsr/logs/rap.log
  • Windows (Default): 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: *******;

• The NSR Hypervisor resource uses a vSphere single Sign-On (SSO) account, a user updated the SSO accounts credentials in VMware; thus causing the credentials in NetWorker to no longer be correct.
• The NSR Hypervisor resource uses an external account. This configuration requires that external authority configurations within vSphere. NetWorker performs "basic auth" with the vCenter using the external account. The vCenter handles the authentication request between vCenter server and external authority provider (for example Microsoft AD).

If NSR Hypervisor account is an external authentication account (AD/LDAP). Consult with the VMware and Domain Administrators. NetWorker is performing "basic authentication" against the vCenter. The domain/external authentication is occurring outside of NetWorker, between the vCenter server and external authority.

To rule out NetWorker, the recommendation is to temporarily configure NetWorker to use another vCenter SSO account. Ideally, the account should be a vSphere SSO account to rule out potential issues between vCenter and external authentication provider (AD/LDAP).
If possible, use the administrator@vsphere.local account, or another local SSO account with required permissions. The permissions required by NetWorker are documented in the NetWorker VMware Integration Guide. NetWorker documentation is available through: Support for NetWorker | Manuals & Documents 

If the account is no longer set in any NetWorker server and continues to be locked, then something else causing the account to lock.

This must be investigated from within VMware. 

• vCenter VPXD logging shows the authentication attempts, but these requests show as 127.0.0.1 and not the system where the authentication request came from.
• vCenter SSO logs record failures but do not include client IP. Meaning it would not be possible to confirm if the request was coming from NetWorker. You see the user, tenant, and result only. 
• vCenter rhttpproxy or frontend logs record client source IP for inbound API/HTTPS requests that reach vCenter’s frontend. On modern VCSA this may be handled by the Envoy frontend rather than the legacy rhttpproxy process, but the principle is the same: The edge log is where the client IP is visible.

Also, check with your network or security team to see if any other systems are routinely contacting the vCenter on port 443. 
Another backup or reporting tool may be using the same account and causing the lock.