Recovering a Lost ESXi or vCenter Password

"Recover the vCenter password" is three different jobs wearing one sentence, and picking the wrong one wastes an afternoon. Before touching anything, decide which credential you have actually lost:

• The ESXi host root account — used at the DCUI, the Host Client, and SSH to a hypervisor. Nothing to do with vCenter.
• The vCenter appliance root account — the Photon (or, on older releases, SLES) operating system underneath the VCSA. This gets you SSH, the console, and the VAMI on port 5480. It is not the account you log into the vSphere Client with.
• The vCenter SSO administrator — administrator@vsphere.local on 5.5 and later, admin@System-Domain on 5.1. This is the vSphere Client login, and it lives in a directory service, not in /etc/passwd.

The procedures differ by credential and by version, and some of them are destructive or unsupported. This walks all three, oldest release to newest, with the traps called out where they bite.

Snapshot or back up the vCenter appliance before you start on it. Every recovery method below that touches the VCSA involves either a boot-loader edit or a directory-service tool, and both can leave the appliance unbootable or the SSO domain inconsistent if a step goes wrong. A cold VM snapshot costs a minute and buys a clean retry.

Part 1 — ESXi host root#

There is no password-reset button on an ESXi host. The DCUI needs the root password to change the root password, which is exactly the loop you are trying to escape. What you actually do depends on how the host is managed.

If the host is joined to Active Directory#

This is the fastest route, and the reason AD join is worth configuring before you need it. A host joined to a domain grants root-equivalent access to members of a designated group. Historically that group was ESX Admins by name, granted automatically:

# On the host, this advanced setting names the group:
Config.HostAgent.plugins.hostsvc.esxAdminsGroup = "ESX Admins"

Log into the Host Client or vCenter with a domain account in that group and you are administrator without ever knowing root.

The automatic ESX Admins grant is a known escalation path — anyone able to create a group by that name in AD inherits the hosts. VMware now recommends renaming the group to something non-obvious and, on current releases, disabling the automatic grant entirely (esxAdminsGroupAutoAdd). If you inherited an estate, check whether this is still wide open before you rely on it — and after you have recovered, close it.

If the host is managed by vCenter (the supported reset)#

vCenter can push a new root password to a host through a host profile, and this is the cleanest supported recovery on 6.x and 7.x:

1. Extract a host profile from a working host, or edit the one already attached.
2. In the profile, under Security and Services → Security Settings → User Configuration → root, set the password-configuration policy to a fixed value and enter the new password.
3. Attach the profile to the locked-out host and Remediate.

The host takes the new root password on remediation without a reboot.

Host profiles require Enterprise Plus licensing. On vSphere 8 host profiles are deprecated in favour of vSphere Configuration Profiles, but they are still present and still work for this. If you are on Essentials or Standard, skip to the reinstall below.

The universal fallback: reinstall, preserving the datastore#

This works on every version, every licence, standalone or clustered, and it is fully supported. Reinstalling ESXi rewrites the hypervisor — and with it the blank-again root password — while leaving your VMs untouched on the datastore.

Boot the ESXi installer for the same or newer version. When it detects the existing install it offers three choices, and the wording matters:

( ) Upgrade ESXi, preserve VMFS datastore          <- keeps the old root password, no help
(o) Install ESXi, preserve VMFS datastore          <- THIS ONE: fresh hypervisor, VMs kept
( ) Install ESXi, overwrite VMFS datastore         <- destroys the VMs

"Install, preserve VMFS datastore" keeps the datastore but wipes the host configuration — networking, vSwitches, iSCSI bindings, the lot. Photograph or export the network config first (esxcli network output from a still-authenticated session, or the host's config in vCenter). After reinstalling you re-register each VM by browsing the datastore, right-clicking the .vmx, and choosing Register VM. Budget for the reconfiguration, not just the reinstall.

If the boot disk and the VMFS datastore share one physical device, read the partition warning carefully — on small single-disk hosts "preserve" is not always offered, and that is the case where you most need a backup.

Auto Deploy / stateless hosts#

A stateless host holds no persistent configuration — it fetches everything, including the root password, from the host profile bound to its deploy rule at boot. There is nothing to reset on the host itself. Fix the password in the host profile, and reboot the host; it re-provisions with the new value. Trying to edit the running host directly is wasted effort because the next reboot discards it.

The unsupported shadow-file edit#

If none of the above is available — a standalone host, no AD, no vCenter, and a datastore you cannot risk on a reinstall — the password hash can be edited directly. This is not supported by VMware, it voids support on that host until reinstalled, and a mistake corrupts the configuration archive. It is a genuine last resort.

ESXi does not store /etc/shadow on disk as a plain file. The configuration lives in a compressed archive on the boot bank: state.tgz, which contains local.tgz, which contains /etc/shadow.

# Boot the host from a Linux live image (GParted Live, etc.) and mount the
# ESXi bootbank partition. Then, in a working directory:
tar xzf /mnt/bootbank/state.tgz          # -> local.tgz
tar xzf local.tgz                        # -> etc/shadow and the rest

# Blank the root hash: change the second field of the root line to empty,
# so root:$6$...:...  becomes  root::...
vi etc/shadow

# Repack in the same order and put it back.
tar czf local.tgz etc
tar czf state.tgz local.tgz
cp state.tgz /mnt/bootbank/state.tgz

Reboot into ESXi and log in as root with no password, then set one immediately at the DCUI. The version differences here are minor — the archive layout is the same from 5.x through 8.x — but the encryption of the config on some 7.x/8.x configurations (TPM-backed) will defeat this entirely, which is by design.

On a host with a TPM and configuration encryption enabled (increasingly the default on 8.x hardware), the archive is sealed to the TPM and cannot be edited offline. That is the feature working as intended. Reinstall is your only route on such a host.

Version summary for ESXi#

Part 2 — the vCenter appliance root account#

Two very different situations get called "lost the vCenter root password", and the fix is different for each.

It is not lost — it has expired#

This is the most common call, and it is not a recovery job. VCSA root passwords expire, by default after 365 days, and an expired root locks you out of SSH and the VAMI while the vSphere Client keeps working (because that is SSO, a separate account). If you can still reach the DCUI or a root shell, just set a new one and, crucially, stop it recurring:

# Set a new password:
passwd

# Check and adjust expiry via the VAMI (Administration > Password expiry),
# or from the shell:
chage -l root
chage -M -1 root        # disables expiry; set a real policy instead if you must

Configure the expiry policy and a notification email in the VAMI now, on every VCSA you run. An expired vCenter root is the single most common self-inflicted lockout, and it always happens the day you need SSH in a hurry.

It is genuinely lost — reset via the boot loader#

With no working root, you reset the password by interrupting the boot loader and dropping to a shell. The appliance OS differs by version, which changes the exact edit.

VCSA 6.5 through 8.x (Photon OS):

1. Reboot the appliance and, at the Photon GRUB menu, press e to edit the boot entry.

2. Find the line beginning linux (the kernel line) and append to the end of it:

   CodeCopy

   rw init=/bin/bash
   

3. Press F10 (or Ctrl-X) to boot into a root shell with no password.

4. Set the new password and reboot:

   BashCopy

   passwd root
   umount /
   reboot -f
   

VCSA 5.x and early 6.0 (SUSE Linux / SLES):

The appliance is SLES-based, not Photon, so it boots into single-user mode rather than an inline init=/bin/bash:

1. At the GRUB menu press a key to stop the countdown, select the boot entry, and press e.
2. Append single (or init=/bin/bash) to the kernel line and boot.
3. At the single-user root prompt, run passwd, then reboot.

If GRUB itself is password-protected — which hardened builds and some appliance versions enable — you cannot edit the boot entry, and this method stops at the menu. In that case the supported path is VMware's KB procedure using the recovery/bootloader password, or restoring the appliance from backup. Do not spend an hour fighting a locked GRUB; go to backup.

The Windows-based vCenter Server of the 5.x/6.x era has no appliance root — its "root" is the Windows administrator of the host it runs on, recovered by normal Windows means.

Part 3 — the SSO administrator (administrator@vsphere.local)#

This is the account you sign into the vSphere Client with, and losing it is separate again from both accounts above. It lives in VMware Directory Service (vmdir), and there is a recovery tool that resets it without the current password — provided you have root/SSH on the appliance, which is why Part 2 sometimes comes first.

vCenter 6.x, 7.x and 8.x — vdcadmintool#

1. SSH into the VCSA as root (recover that first if needed) and enter the shell.

2. Run the directory admin tool:

   BashCopy

   /usr/lib/vmware-vmdir/bin/vdcadmintool
   

3. Choose option 3, "Reset account password".

4. Enter the full UPN of the account:

   CodeCopy

   administrator@vsphere.local
   

5. The tool prints a new, randomly generated password. It does not let you choose one — copy the generated value exactly, log in with it, and change it to something of your own immediately.

Please enter account UPN : administrator@vsphere.local
New password: 8Kq!v2$w....Zx

The generated password is long and includes characters a terminal may not copy cleanly — watch for a trailing space or a mangled symbol. If the first login fails, re-run the tool rather than assuming the account is still broken; each run issues a fresh password.

If your SSO domain is not the default vsphere.local, use your actual domain in the UPN — check it in the vSphere Client under Administration → Single Sign-On → Configuration, or you will reset a UPN that does not exist and conclude, wrongly, that the tool failed.

vCenter 5.5#

5.5 also uses vmdir and a vdcadmintool, in the SSO installation directory rather than the Photon path above. On the Windows vCenter it is under the VMware Identity Services / SSO program directory; on the 5.5 appliance it is under /usr/lib/vmware-sso/. The reset flow — option 3, enter administrator@vsphere.local, receive a generated password — is the same.

vCenter 5.1 — a different mechanism entirely#

5.1 is the outlier and the reason "just run vdcadmintool" is wrong advice on old estates. Its SSO stored the administrator account (admin@System-Domain) in an RSA/SQL database, not vmdir, and recovery meant running a password-reset script against that database (ssolscli / the RSA utilities, or a direct SQL update against the SSO schema). If you are genuinely on 5.1, treat it as its own project, confirm the exact build, and follow the version-specific VMware KB — the tooling does not carry forward.

If you are recovering a 5.1 or 5.5 environment under pressure, the honest fastest path is often to stand up a current vCenter and re-add the hosts rather than reverse-engineer a decade-old SSO database. Extended support for those releases ended years ago; a recovered 5.1 is a recovered liability.

After you are back in#

Recovery is the emergency; the follow-up is what stops the next one:

• Record the accounts. All three — ESXi root, VCSA root, SSO administrator — belong in the password manager, not in one engineer's memory. They are distinct credentials and each locks you out differently.
• Set, and monitor, the VCSA root expiry. The default 365-day expiry is a scheduled outage. Give it a real policy and an alert.
• Join hosts to AD, or to vCenter, deliberately. Both give you a way in that does not depend on the local root password, which is the difference between a five-minute fix and a reinstall.
• Close the ESX Admins gap if your recovery relied on it, so it is not also an attacker's way in.

The pattern across all of this is that the supported, boring preparation — AD join, host profiles, a monitored expiry, a current backup — turns every one of these recoveries from an afternoon into a login. The unsupported shadow-file edits and GRUB surgery are there for the estates where nobody did the boring part.