Revoke a Departed Administrator's Access Across a Hosted Estate

Direct answer: For a planned departure, build the inventory before you revoke anything; for a hostile departure or suspected compromise, contain first and complete the inventory straight after. List every route the person had: directory accounts, cloud identity sessions and devices, vCenter permissions and SSO group memberships, local ESXi accounts and host permissions, jump hosts, SSH keys, and every shared secret they knew. Then remove access in a planned order. In a hybrid estate, Microsoft's documented order is to disable the on-premises account, reset its password twice, disable the Entra account, revoke its sessions and disable its devices. Remove the person's vCenter and ESXi permissions and SSH keys individually. Rotate shared credentials, because disabling a personal account does nothing to a password the person memorised. Record evidence for each system as you go. Expect a tail: access tokens that were already issued keep working until they expire (Microsoft's pages give lifetimes from about an hour to over a day depending on client and policy), unless the resource enforces continuous access evaluation, so confirm in each high-value application.

Why it matters

A departing administrator is rarely one account. Over the years they collect admin accounts, a cloud identity, a local vCenter SSO user, appliance root passwords, SSH keys and service-account credentials. Offboarding usually handles the HR-linked directory account well and the rest poorly, because the rest is not tied to the person's name anywhere central.

NIST SP 800-53 control AC-2 (account management) requires notification on termination or transfer, disabling or removal by policy, changing shared authenticators when someone leaves the group, alignment with personnel processes and periodic review. This article turns those obligations into steps for a hosted estate.

The procedure applies to a resignation, a contract ending or a dismissal; only timing differs. For a hostile departure or suspected compromise, revocation happens when the person is told, with as much of the inventory ready beforehand as possible. Microsoft's Entra guidance covers compromise, termination and insider-threat scenarios with the same mechanism.

How it works

Access persists in three forms, and each needs a different action.

Sessions and tokens add a time element. In Entra ID, revoking a user's sessions stops new tokens being issued. Microsoft's revoke-access page says access tokens last one hour by default and existing access ends when the current token expires. Its access-token page is more detailed: a random 60 to 90 minutes by default, two hours for clients such as Teams and Microsoft 365 in tenants without Conditional Access, configurable by policy, and 20 to 28 hours for long-lived tokens where continuous access evaluation provides event-driven revocation. Session cookies an application issues after sign-in are controlled by the application, and Entra ID cannot revoke them. For applications and resources that support continuous access evaluation, a revocation event can end access before the token expires; for others, the token's own lifetime applies. On premises, an open RDP session or SSH connection does not end when the account is disabled or the key removed; it has to be found and ended on the host.

Read-only checks

None of these was run for this article. Each says what privilege it needs and whether it changes anything. Do the discovery before the departure date wherever you can, and keep the output as evidence.

1. Build the inventory sheet

Start a table with one row per system: system, account or key, how found, grant held, action, who acted, timestamp, evidence reference. Seed it from the HR or contract record, handover notes, your privileged-access list and their change records. Ask the manager and a peer which shared logins they used; those rows are the most often missed.

2. Active Directory: accounts and group memberships

Find every account that belongs to the person. Personal and admin accounts often have different names, so search by display name, employee ID or another attribute you use, not just sAMAccountName. Then list each account's groups:

# Read-only. Needs read access to the directory (any domain user by default)
# and a reachable global catalog.
Get-ADPrincipalGroupMembership -Identity 'j.smith-adm' |
    Select-Object Name, GroupCategory, GroupScope, DistinguishedName

Microsoft documents that this cmdlet needs a global catalog; without one it returns a non-terminating error. If an error appears, treat the list as incomplete, not empty. For resource-domain local groups in another domain, use -ResourceContextServer.

Also look for accounts the person created and controls, such as service accounts whose password only they know, or accounts naming them in the description or manager field. These belong in the secret-rotation rows too.

3. Microsoft Entra ID: account, devices and roles

Using the Microsoft Graph PowerShell SDK, the revoke-access page connects with the User.ReadWrite.All and Directory.AccessAsUser.All scopes for the revocation itself. For discovery only, read the account and its registered devices:

# Read-only queries. For discovery alone, connect with read-only scopes
# your tenant policy allows, not the write scopes above.
Get-MgUser -UserId 'j.smith@example.com' -Property Id,DisplayName,AccountEnabled,OnPremisesSyncEnabled
Get-MgUserRegisteredDevice -UserId 'j.smith@example.com' -All -ErrorAction Stop

-All follows every page of results, as in Microsoft's example; without it you may see only the first page. If the command reports an error, treat the device list as incomplete. Record each returned device so Step 3 can be checked against the whole list.

Note whether the account is synchronised from on premises (OnPremisesSyncEnabled). If so, the on-premises disable is authoritative and reaches Entra on the next synchronisation cycle; Step 3 still disables the cloud account directly so sign-in stops without waiting for that cycle. Also list any directory roles and application ownership the person holds through the Entra admin centre or Graph. This article's sources do not cover role-assignment cmdlets; check current Graph documentation before relying on a query.

The AzureAD and MSOnline modules were deprecated on 30 March 2024; migrate older offboarding scripts to the Graph SDK.

4. vCenter: permissions and SSO group membership

vCenter has several separate places where an identity can hold rights, and they are easy to confuse.

• Object permissions on inventory objects (data centres, clusters, folders, VMs). PowerCLI can list them by principal:

powershell # Read-only. Needs a vCenter session with permission to read permissions. Get-VIPermission -Principal 'EXAMPLE\j.smith-adm'

Also check the groups the person belonged to; a group grant still works for every remaining member. The PowerCLI reference describes Get-VIPermission as returning permissions on inventory objects only. - Global permissions. These are separate from object permissions, and this article does not rely on Get-VIPermission to show them. Review them in the vSphere Client, using your version's documentation for where they appear and what they cover, and record each entry for the person and their groups. - SSO group membership. Broadcom KB 391733 explains that holding the Administrator role through global permissions does not grant management of the SSO domain itself. That comes from membership of the built-in SSO Administrators group in the SSO domain (for example vsphere.local). To list that group's members, use the vSphere Client (Administration, Single Sign On, Users and Groups, Groups) or, on the vCenter appliance shell, run:

bash # Read-only listing. Runs on the vCenter appliance as root; dir-cli prompts # for SSO administrator credentials. Do not pass a password on the command line. /usr/lib/vmware-vmafd/bin/dir-cli group list --name Administrators

• Local SSO users created for the person (for example j.smith@vsphere.local), separate from their AD identity. List these in Users and Groups in the vSphere Client.

5. ESXi hosts: local accounts and host permissions

Each ESXi host has its own local accounts and permissions, independent of vCenter. ESXCLI 8.0.2 documents two read-only listings:

# Read-only. Run in the ESXi shell or via SSH with an administrative account.
esxcli system account list
esxcli system permission list

The first lists local accounts; the second lists permissions on the host itself, which can include domain identities on an AD-joined host. Check every host; a project may have added an account to a few. With lockdown mode, also review the host's exception users (not covered by this article's sources).

6. Remote Desktop, jump hosts and management servers

On each jump host, RD Session Host and management server, check four things:

• Local groups such as Administrators and Remote Desktop Users, for the person's accounts or groups.
• Open or disconnected sessions of the person, for example with quser (read-only).
• Scheduled tasks running as the person, or running scripts from a location only they controlled (Get-ScheduledTask, inspect each principal; read-only).
• Saved credentials in shared tool profiles, such as connection managers with stored passwords. These are shared secrets for the rotation rows.

7. SSH keys on Linux hosts and appliances

OpenSSH sshd reads authorised public keys from the files named by AuthorizedKeysFile (default ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2). Each line holds optional options, the key type, the key and a comment, and the manual states the comment is not used for authentication: jsmith@laptop is only probably the person's key, and a misleadingly labelled key can still be theirs.

# Read-only. Shows fingerprints, not the keys themselves. Needs read access to
# the file (root for other users' files).
ssh-keygen -l -f /home/deploy/.ssh/authorized_keys

The reliable way to tie a key to a person is to compare its fingerprint with the public key they registered, if your process kept a record. Check shared accounts such as root, deploy or backup users too; a leaver's key is most often left behind there.

Files are not the only source. sshd_config(5) also documents AuthorizedKeysCommand (a program that returns keys), TrustedUserCAKeys with AuthorizedPrincipalsFile or AuthorizedPrincipalsCommand (user certificates signed by a trusted CA, which work even when the raw key is in no file), RevokedKeys, and Match and Include blocks that change these per user or address. Read the effective configuration for an affected account rather than the file alone:

# Read-only. Run as root on the host. Use the -f file and options the
# running sshd uses (see its service unit or process list).
sshd -G -f /etc/ssh/sshd_config \
  -C user=deploy,host=jump01.example.com,addr=192.0.2.10,laddr=198.51.100.5,lport=22 |
  grep -Ei '^(authorizedkeys|authorizedprincipals|trustedusercakeys|revokedkeys|port|listenaddress)'

Match can also test the local address and port, so repeat this per listener (laddr, lport) and per source the person used. If the installed sshd lacks -G, use -T (check man sshd on the host).

If a key command or a user CA is in use, the person's access is removed through that mechanism (the key source behind the command, a principal entry, or adding their certificate or key to the RevokedKeys list), not by editing authorized_keys. Never remove a shared CA key to revoke one person; that locks out every user it signs for. If your estate deliberately excludes these mechanisms, note that in the inventory.

8. Shared and service secrets

List every secret the person had seen or held: appliance root and administrator@vsphere.local passwords, break-glass and service accounts, storage and backup target credentials, provider API keys, firewall and switch passwords, and vault entries they could read. AC-2 requires changing shared authenticators when someone leaves the group. Use vault access history if it exists; otherwise assume they knew every secret they could read.

Interpreting the results

Decision guidance

Run changes in this order; each step says how to verify it and undo it if the wrong object was changed. Use change control for anything affecting other people, such as rotating a shared password.

Step 1: Re-home what depends on the person

Routine departure: before the cutoff, move scheduled tasks, service accounts and integrations that run as the person's account to a proper service identity. Disable first and jobs fail, and pressure to re-enable the leaver's account follows.

Hostile departure or suspected compromise: do not wait for this step. Run Steps 2, 3 and 6 (disable, revoke, remove keys and sessions) at once with the authorised decision makers, accept that jobs running as the person will fail, record each failure, and repair it afterwards under an identity you trust. Do not re-enable a compromised account to keep a job running.

• Verification: Run each moved job once under its new identity and confirm the expected result.
• Rollback: Restore the task's previous principal. Do this only while the person's account is still enabled and approved for this purpose.

Step 2: Disable on-premises AD accounts and reset passwords twice

For hybrid identities, Microsoft's revoke-access guidance is to disable the account with Disable-ADAccount and then reset the password twice. The double reset is there because of pass-the-hash risk and replication delay. Generate each password at random and do not record it; nobody needs it while disabled.

# Changes state. Needs rights to disable the account and reset its password.
Disable-ADAccount -Identity 'j.smith-adm'

# Prompt for a random value; never paste a password into a script or this document.
Set-ADAccountPassword -Identity 'j.smith-adm' -Reset -NewPassword (Read-Host -AsSecureString 'New random password')
# After replication, repeat the reset with a different random value.

Repeat for every AD account belonging to the person.

• Verification: Run Get-ADUser -Identity 'j.smith-adm' -Properties Enabled,PasswordLastSet on more than one domain controller once replication has run.
• Rollback: If the wrong account was disabled, run Enable-ADAccount and give the owner a new password through your normal reset process; the earlier password cannot be recovered. Disabling keeps group memberships, which keeps rollback simple; strip them later under your retention policy.

Step 3: Entra ID: disable, revoke sessions, disable devices

Disable the Entra account directly, for cloud-only and synchronised accounts alike: clear Account enabled in the admin centre, or run Update-MgUser -UserId <id> -AccountEnabled:$false. Microsoft's emergency procedure does this as well as the on-premises disable in Step 2, because waiting for synchronisation leaves the cloud account enabled while sync is delayed or unhealthy. For a synchronised account, confirm after the next cycle that it is still disabled. Then revoke sessions with Revoke-MgUserSignInSession -UserId <id> and disable the user's registered devices. Microsoft's example pipes Get-MgUserRegisteredDevice -All into Update-MgDevice -AccountEnabled:$false; reconcile the devices it changed with the list from Check 3.

Microsoft names the roles: User Administrator for non-admin users, Privileged Authentication Administrator for an administrator, Cloud Device Administrator for devices. Apps with automatic provisioning pick up the change within 20 to 40 minutes; others need manual deprovisioning. An Intune wipe runs only once the device is online.

• Verification:
• Read AccountEnabled back.
• Check the sign-in logs for new successful sign-ins after the revoke time.
• Set no fixed deadline for already-issued tokens; it depends on each resource's token lifetime and continuous access evaluation (see How it works). Close the step when each high-value resource's logs show no activity by the person after its token lifetime, or the resource confirms revocation.
• Application-issued session cookies are outside Entra's control, and using an existing token does not always create a new Entra sign-in event, so check high-value applications directly.
• Rollback: Re-enable the account and devices. A session revoke cannot be undone, but it only forces sign-in again.

Step 4: vCenter and SSO

Remove the following:

• Object permissions and global permissions held directly by the person's identities.
• Their membership of AD groups used for vCenter roles. Step 2 does not do this, because disabling keeps memberships.
• Their membership of the SSO Administrators group, and any other SSO groups.
• Any local SSO users created for them.

PowerCLI documents Remove-VIPermission alongside Get-VIPermission for object permissions.

• Verification:
• Repeat the discovery in Check 4 and confirm no entries remain for the person.
• If the person knew administrator@vsphere.local, rotate it in Step 7 and confirm that tools using it still work.
• Rollback: Re-add the specific permission with the same role and propagation setting. This is why the inventory records the role and propagation for each grant.

Step 5: ESXi hosts

On each host, remove the person's local accounts (esxcli system account remove --id <name>). Remove host permissions for their identities by setting them to the NoAccess role, or by removing them in the host client. ESXCLI documents system permission set with --id and --role, and notes that ESXi local groups are not supported for that command. If any local ESXi account password was shared, add it to Step 7.

• Verification: Re-run esxcli system account list and esxcli system permission list on every host.
• Rollback: Re-create the account or permission on the specific host. Local account passwords must be set again.

Step 6: Jump hosts, RDS and SSH

Do the following on each system in the inventory:

• Remove the person's identities or groups from local groups.
• Sign out their sessions after the account disable.
• Delete their lines from every authorized_keys file that held them. Edit the file rather than replacing it, and keep a copy of the original with restrictive permissions as evidence.
• Where Check 7 found a key command, user CA or principal source, revoke the person's key, certificate or principal through that mechanism instead.
• End their existing SSH connections. Removing a key does not close a connection already open, including non-interactive or forwarding-only ones. List connections on every port sshd listens on, not just 22 (ss -tlnp shows them, matching the port and listenaddress lines above), for example ss -tnp state established '( sport = :22 or sport = :2222 )' and who, both read-only. Match them to the person's source addresses and login times, and end only those through your reviewed procedure, never other users of a shared account.

For future contractors, the sshd expiry-time= and from= key options let a key expire on its own or work only from known addresses.

• Verification:
• RDP: confirm with quser on each RD Session Host and jump host that none of the person's sessions remain. quser covers Remote Desktop sessions only.
• SSH: confirm the fingerprint is gone with ssh-keygen -l -f, re-run the established-connection check on every listening port and see none of the person's connections, and confirm a fresh authentication with the person's key or certificate is refused (from a controlled test, with their key material only if your process holds it), checking the host's authentication log.
• Ask a remaining administrator to confirm that their own key still works on shared accounts.
• Rollback: If a wrong line was removed, restore only that line from the saved copy; restoring the whole file could bring back revoked keys or overwrite another administrator's changes. Keep the saved copy as evidence.

Step 7: Rotate shared secrets

For each secret in Check 8:

1. Rotate it.
2. Update every consumer (scripts, backup jobs, monitoring, delivery targets).
3. Confirm each consumer works.

Rotate the highest-privilege secrets first:

• administrator@vsphere.local
• appliance root accounts
• break-glass accounts
• domain-level service accounts

Where a system supports two valid credentials at once, create the new key, switch consumers, then remove the old one; a single shared password cannot do this. F29 covers the pattern for delivery credentials.

• Verification: Each consumer's next scheduled run succeeds, and the old secret no longer authenticates.
• Rollback: Re-apply the previous secret only as a short emergency measure, and only if the person's departure was not hostile. Otherwise fix the consumer forward.

Step 8: Close the record

Attach before and after outputs, timestamps and who acted to the offboarding ticket. Schedule account deletion under your retention policy and set a review date for anything open, such as an unclaimed SSH key; AC-2's periodic review is the backstop.

What not to do

• Do not delete accounts on day one. A disabled account keeps its memberships and audit trail and can be re-enabled; delete under your retention policy.
• Do not re-enable a leaver's account "temporarily" to keep a job running. Re-home jobs before a planned cutoff; after an urgent containment, repair them under a trusted identity.
• Do not paste passwords into scripts, tickets or chat while rotating; use prompts, a vault or generated values.
• Do not rotate a shared credential without a list of its consumers, or the outage gets blamed on the wrong change.
• Do not use this procedure on someone else's tenant without that tenant's authority. Revocation in a hosted estate is done by, or with the written agreement of, the party that owns the accounts.

Limitations

• The commands come from vendor documentation for the versions in the scope. They were not run for this article, and output formats can change between releases.
• The vSphere 8 security guide pages for global permissions and SSO users could not be retrieved, so this article gives no menu path or scope for global permissions; whether Get-VIPermission returns them was not confirmed.
• The ESXi lockdown-mode exception users list, Entra role-assignment queries and application-ownership queries are mentioned but not sourced in detail here.
• Applications with their own user stores (line-of-business systems, firewalls, switches, storage arrays, backup consoles, provider portals) each need their own row and the vendor's own procedure. This article cannot list them.
• The double-password-reset guidance is Microsoft's for hybrid identities. Replication timing in your domain decides the interval between resets.
• Nothing here detects access the person may already have used to plant persistence. If misuse is suspected, treat it as a security incident and involve your incident-response process, not just offboarding.

Acceptance checklist

• [ ] Inventory sheet completed before revocation (planned departure) or straight after containment (hostile or compromised), with one row per account, grant, key and secret.
• [ ] Scheduled tasks and services re-homed and tested under new identities; for an urgent containment, each broken job recorded and repaired under a trusted identity.
• [ ] All AD accounts for the person disabled, passwords reset twice with random values, and checked on more than one DC.
• [ ] Entra account disabled directly (and still disabled after the next sync for synchronised accounts), AccountEnabled read back as false, sessions revoked, all devices disabled; sign-in logs and high-value application logs checked after the revoke time.
• [ ] Applications needing manual deprovisioning handled and recorded.
• [ ] vCenter object and global permissions, SSO group memberships and local SSO users removed; discovery re-run is clean.
• [ ] Every ESXi host's local accounts and host permissions re-listed and clean.
• [ ] Jump host, RDS and management server groups and RDP sessions cleared (quser).
• [ ] SSH access removed through every configured mechanism (authorized_keys files, key commands, user CA and principals) on every host and shared account, confirmed by fingerprint and by the daemon's effective configuration for each listener; the person's SSH connections ended on every listening port; a fresh authentication refused.
• [ ] Shared and service secrets rotated with every consumer confirmed working.
• [ ] Evidence attached to the ticket; deletion date and review date set.

References

All accessed 2 November 2026.

• Microsoft Learn, "Revoke user access in an emergency in Microsoft Entra ID": scenarios (compromise, termination, insider), required roles, hybrid order (Disable-ADAccount, double password reset), Entra disable and revoke, Graph cmdlets, one-hour default access token (the access-token page below gives more detail), application session tokens not revocable by Entra, continuous access evaluation, provisioning every 20 to 40 minutes, device disable and Intune wipe, AzureAD/MSOnline deprecation. https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
• Microsoft Learn, "Disable-ADAccount": identity forms and pipeline use. https://learn.microsoft.com/en-us/powershell/module/activedirectory/disable-adaccount
• Microsoft Learn, "Access tokens in the Microsoft identity platform": variable 60 to 90 minute default lifetime, two-hour defaults for some clients, configurable lifetimes, 20 to 28 hour long-lived tokens with continuous access evaluation. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens
• OpenBSD manual, sshd_config(5): AuthorizedKeysFile, AuthorizedKeysCommand, AuthorizedPrincipalsFile and AuthorizedPrincipalsCommand, TrustedUserCAKeys, RevokedKeys, Match and Include. https://man.openbsd.org/sshd_config
• Microsoft Learn, "quser": lists user sessions on a Remote Desktop Session Host server. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/quser
• Microsoft Learn, "Get-ADPrincipalGroupMembership": global catalog requirement, non-terminating error, ResourceContextServer. https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adprincipalgroupmembership
• Broadcom Developer, PowerCLI "Get-VIPermission": permissions on inventory objects, Entity and Principal parameters, related Remove-VIPermission. https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/get-vipermission
• Broadcom Knowledge Base 391733, "Users with Administrator role unable to manage SSO": global Administrator role versus SSO Administrators group membership, dir-cli group listing, vSphere Client path. https://knowledge.broadcom.com/external/article/391733/users-with-administrator-role-unable-to.html
• Broadcom Developer, ESXCLI 8.0.2 command reference, esxcli system namespace: account list/remove, permission list/set, local groups not supported. https://developer.broadcom.com/xapis/esxcli-command-reference/8.0.2/namespace/esxcli_system.html
• OpenBSD manual, sshd(8): AuthorizedKeysFile default, authorized_keys line format, comment field not used, expiry-time= and from= options. https://man.openbsd.org/sshd.8
• NIST, SP 800-53 Revision 5 (Update 1), control AC-2 Account Management: termination and transfer notification, disable or remove, change shared authenticators on removal, alignment with personnel processes, review. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Related articles

• How to harden VMware without breaking operations or recovery
• Scheduled Jobs After Migration: Prevent Duplicate Work

• How to back up and rehearse recovery of the vCenter appliance

• Windows LAPS: Deploy It Safely and Recover the Local Administrator After a Restore

• SFTP Host Key Changed: Verify It and Rotate Keys Safely
• S3 Credentials for Automated Delivery: Least Privilege and Rotation

Learning notes

1. A leaver holds three kinds of access: accounts, grants to those accounts, and secrets they know. Each needs a different action, and disabling the directory account only handles the first.
2. Build the inventory before revoking (for a planned departure; contain first if compromise is suspected): AD group memberships, Entra devices, vCenter object and global permissions, SSO Administrators membership, local SSO and ESXi accounts, SSH keys, and shared secrets.
3. For hybrid identities, Microsoft's order is: disable in AD, reset the password twice, then disable in Entra, revoke sessions and disable devices. Issued access tokens last until they expire, and the lifetime varies by client and policy, so close revocation on each resource's own evidence.
4. vCenter's global Administrator role and the SSO Administrators group are different things. ESXi local accounts and SSH keys are outside both.
5. Re-home dependent jobs before a planned cutoff (never delay containment for it), disable rather than delete, rotate shared secrets with a consumer list, and keep evidence for each row.