# Recovering a Lost ESXi or vCenter Password

> Three different credentials, and the version-specific way back into each

Canonical: https://everettkildare.com/blog/recovering-a-lost-esxi-or-vcenter-password
Author: Everett Kildare
Published: 2026-07-31
Updated: 2026-11-01

"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.

> [!IMPORTANT]
> 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.

> [!WARNING]
> 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.

> [!NOTE]
> Host profiles require **Enterprise Plus** licensing. vSphere 8 introduced vSphere Configuration Profiles as their successor, and vSphere 9 deprecates host 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
```

> [!CAUTION]
> "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`.

```bash
# 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.

> [!CAUTION]
> 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

| Version | AD join | Host profile reset | Reinstall preserving VMFS | Offline shadow edit |
|---|---|---|---|---|
| 5.5 / 6.x | Yes | Yes (Ent+) | Yes | Yes |
| 7.x | Yes | Yes (Ent+) | Yes | Yes, unless config-encrypted |
| 8.x | Yes | Yes (Ent+) | Yes | Blocked if TPM-sealed |

## 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 **90 days** on 6.5 and later (365 on earlier releases), 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:

```bash
# 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
```

> [!TIP]
> 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:

   ```
   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:

   ```bash
   passwd root
   umount /
   reboot -f
   ```

**VCSA 5.x and 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`.

> [!WARNING]
> 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:

   ```bash
   /usr/lib/vmware-vmdir/bin/vdcadmintool
   ```
3. Choose option **`3`, "Reset account password"**.
4. Enter the full UPN of the account:

   ```
   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.

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

> [!NOTE]
> 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`, and the flow is the same: option 3, enter the administrator account, receive a generated password. Where the tool lives depends on the platform:

| 5.5 platform | `vdcadmintool` location |
|---|---|
| vCenter Server Appliance (SLES) | `/usr/lib/vmware-vmdir/bin/vdcadmintool` — the same path the later Photon appliances use |
| Windows SSO server (default install) | `C:\Program Files\VMware\Infrastructure\VMware\CIS\vmdird\vdcadmintool.exe` — run it from an elevated command prompt |

VMware's own 5.5 article (KB 2146225, "How to unlock and reset SSO administrator password in vSphere 5.5") no longer resolves since the move to Broadcom's knowledge base. The paths above come from contemporaneous write-ups listed under Sources, not from a live VMware page. A non-default Windows install directory moves the `vmdird` folder with it, so search the install drive for `vdcadmintool.exe` if the default path is empty.

### 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 was the RSA-based product. It kept the administrator account (`admin@System-Domain`) in its own database, not vmdir, and has no `vdcadmintool`. Recovery is the SSO server's `rsautil` utility:

```text
# Windows SSO server (default install directory)
cd "C:\Program Files\VMware\Infrastructure\SSOServer\utils"
rsautil reset-admin-password

# 5.1 appliance, as root
cd /usr/lib/vmware-sso/utils
./rsautil reset-admin-password
```

It prompts for the SSO **master password** set at installation, then the admin account name and its new password. That makes the master password the real dependency. If nobody has it and no other SSO administrator account exists, there is no supported reset, and the documented way out is to reinstall SSO. The VMware article for this was KB 2034608, "Unlocking and resetting the vCenter Single Sign-On administrator password". Like KB 2146225, it is no longer live at its old address. If you are genuinely on 5.1, treat it as its own project and confirm the exact build first, because the tooling does not carry forward.

> [!TIP]
> 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 90-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.

## Sources

- [Methods to recover the ESXi host root password](https://knowledge.broadcom.com/external/article/393496) — Broadcom's supported options: host profile, Configuration Profiles, PowerCLI, reinstall preserving VMFS.
- [Reset ESXi host root password using Host Profile](https://knowledge.broadcom.com/external/article/323617) — profile path, fixed-password policy, Enterprise Plus requirement, no reboot.
- [Secure Default Settings for ESXi Active Directory integration](https://knowledge.broadcom.com/external/article/369707) — the `ESX Admins` escalation and the `esxAdminsGroupAutoAdd` workaround.
- [Change or Reset the root account password in vCenter Appliance](https://knowledge.broadcom.com/external/article/322247) — Photon GRUB `rw init=/bin/bash` reset, F10, `passwd`, `umount /`, `reboot -f`.
- [Resetting forgotten or locked vCenter Server SSO administrator password](https://knowledge.broadcom.com/external/article/326186) — `vdcadmintool` path, option 3 and the UPN prompt.
- [Login to Management Interface (VAMI) of a vCenter or Platform Service Controller fails with the message "Exception in invoking authentication handler User password expired"](https://knowledge.broadcom.com/external/article?legacyId=75107) — 90-day default root expiry on 6.5 and later, 365 days before.
- [Troubleshooting Tools for Networking on vCenter Server Appliance 6.5 and Above](https://knowledge.broadcom.com/external/article?legacyId=2147148) — VCSA 6.5+ is Photon OS; earlier appliances were SLES.
- [How to reset administrator@vsphere.local password in vCenter 5.5](https://elgwhoppo.com/2013/10/22/how-to-reset-administratorvsphere-local-password-in-vcenter-5-5/) — 5.5 `vdcadmintool` locations on the appliance (`/usr/lib/vmware-vmdir/bin/`) and Windows (`...\Infrastructure\VMware\CIS\vmdird`), and option 3.
- [vCenter 5.x/6.x: How to reset administrator@vsphere.local account password](https://www.provirtualzone.com/vcenter-5-x6-x-how-to-reset-administratorvsphere-local-account-password/) — corroborates the appliance path and the Windows `CIS\vmdird` location.
- [Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608)](https://virtualization24x7.blogspot.com/2013/07/unlocking-and-resetting-vcenter-single.html) — a repost of VMware KB 2034608: `rsautil reset-admin-password` from `SSOServer\utils` on Windows and `/usr/lib/vmware-sso/utils` on the appliance.
- [vCenter Single Sign On (SSO) password reset](https://www.ivobeerens.nl/blog/2013/05/vcenter-single-sign-on-sso-password-reset/) — the RSA-era `rsautil` reset needs the SSO master password; without it and with no other admin, there is no supported reset short of reinstalling SSO.
- [Securing the ESXi Configuration](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-security/securing-esxi-hosts/securing-the-esxi-configuration.html) — configuration encryption from 7.0 U2 and TPM sealing of the key.