VCF Installer says "User is not authorized" and your password is correct (admin@local is locked)
LOCAL_ACCOUNT_LOCKED surfaces in the UI as an authorization error, not a lockout. The lockout does not expire. Reboot the appliance, or restart commonsvcs.
Your password is probably fine. admin@local is locked, and the UI reports it as “User is not authorized” rather than as a lockout. The lockout does not expire on its own. The quickest fix is to reboot the appliance from the hypervisor side, which needs no SSH and no credentials. Auth came back about two minutes after boot.
Why this is so confusing
The message names the wrong problem. You get an authorization error, so you check the password, and the password is right. In my case the API had been authenticating with that exact 20 character string all day while the UI refused it.
The real error code is LOCAL_ACCOUNT_LOCKED. You will see that in the API response, not in the UI.
What locks it
Failed login attempts. The trap is that the account is admin@local, not admin, and typing admin in the UI is a failed attempt like any other. A few of those and you are locked out with a password that was never wrong.
Fixing it without SSH
Reboot the appliance. Graceful shutdown and power on from the hypervisor side restarts commonsvcs along with everything else, and it needs no credentials at all, which matters because the thing you have lost is a credential.
This is the option to reach for first. It is also the one that works when SSH is the thing you cannot use.
Fixing it with SSH
Broadcom’s KB gives the direct fix:
systemctl restart commonsvcsSSH in as the vcf user and elevate to root. Do not try to SSH as root: root is not the login account on this appliance, which is also why root SSH attempts fail in a way that looks like a separate problem. The KB says to wait five minutes before logging in again.
One thing a reboot does not reliably fix
The appliance’s own SSH account can lock out too, from repeated connection attempts, and that is a different lockout from admin@local.
In this build a reboot restored the API and the admin@local login but did not clear the SSH account lockout. Later, a vcf user SSH lockout survived two reboots.
So if you are locked out of both, expect the reboot to give you the API back and expect to still be shut out of the shell.
Verified, and what is inference
Verified here: the LOCAL_ACCOUNT_LOCKED code, the misleading “User is not authorized” message in the UI, that the stored password was never wrong, that a hypervisor side reboot recovered authentication in about two minutes, and that a reboot restored the API without clearing an SSH account lockout.
From Broadcom’s KB, not tested here: the systemctl restart commonsvcs path and the five minute wait. The KB is written against VCF Installer 9.0; the behaviour matched on 9.1.0, but I fixed it by rebooting rather than by running the command, so I have not personally confirmed the command on 9.1.
Inference: that the lockout came from UI attempts using admin instead of admin@local. It fits (the API was succeeding with the same credential throughout) but nothing logged the failed attempts in a way I could read back.
The wider story of building this lab, including how an agent drove most of it, is in I Let Claude Code Deploy My VCF 9.1 Home Lab, and This Is What Happened.
Source: Broadcom KB 403316, unlocking admin@local on the VCF Installer appliance.