Getting Started — JIT Local Admin

Overview

This guide configures the JIT Temp Local Admin access pattern for a standalone VMware ESXi host. On checkout, the broker creates an ephemeral local account on the host and grants the Administrator role at the root inventory object. On checkin, the role is removed and the account is deleted. The same account works from the ESXi web UI and SSH — the account is created with shell access enabled.

Reference scripts: britive/access-broker-examples/VMware/ESXi/permissions/temp-local-admin/.

Before You Begin

A Britive tenant with administrator access.
A standalone VMware ESXi 7.0 or 8.0 host (not managed through vCenter).
vSphere Standard or higher license on the host. Free / unlicensed hosts disable write API calls after the 60-day evaluation and the checkout will fail.
A Britive Access Broker already deployed and connected to your tenant. The broker host needs:
- python3 3.8+ (standard library only — no third-party packages)
- Outbound TCP 443 to each target ESXi host

How It Works

    sequenceDiagram
    actor User
    participant Britive
    participant Broker
    participant ESXi as ESXi Host

    User->>Britive: Request JIT access
    Britive->>Britive: Policy evaluation (approvals, IP, time, ITSM ticket)
    Britive->>Broker: Checkout — run checkout.py
    Broker->>ESXi: SOAP POST to /sdk — Login on ha-sessionmgr (service account)
    Broker->>ESXi: CreateUser on ha-localacctmgr (ephemeral account, shellAccess=true)
    Broker->>ESXi: SetEntityPermissions on ha-authmgr (Administrator role at ha-folder-root)
    Broker-->>User: Web UI URL, SSH command, username, ephemeral password
    User->>ESXi: Sign in via host UI or SSH with returned credentials

    Note over User,ESXi: Checkin (manual or expiry)
    Britive->>Broker: Checkin — run checkin.py
    Broker->>ESXi: SOAP POST to /sdk — RemoveEntityPermission (drops role binding)
    Broker->>ESXi: RemoveUser (deletes the account)

The JIT account name is derived from the requestor’s email local part — jane.doe@example.com becomes jane.doe — so the audit trail on the ESXi host names the real person, not a synthetic JIT identifier.

Name collision: because the JIT account name has no prefix, a checkout for jane.doe@example.com will hit any pre-existing local account named jane.doe. The script’s “AlreadyExists → UpdateUser” path will overwrite that account’s secret, and checkin will then delete it. Keep ESXi local accounts under Britive’s exclusive control, or add a prefix in jit_username() (e.g. b-jane.doe).

Configure the ESXi Host

Create the service account

Go to Manage → Security & users → Users → Add user.
Create the service account — e.g. britive-svc — with a strong password.

Assign the Administrator role

Go to Host → Actions → Permissions → Add user.
Select britive-svc and assign the Administrator role at the root inventory object with Propagate to children checked.

(Optional) Use a custom least-privilege role

If your security policy does not permit a standing Administrator account for the broker, create a custom role with at minimum:

Host.Local.CreateUser
Host.Local.RemoveUser
Host.Local.ManageUserGroups
Authorization.ModifyPermissions

Replace Administrator with this custom role on the service account.

(Optional) Enable SSH on the host

The JIT account is created with shell access enabled, but the host’s SSH service must be running for the SSH path to work. SSH is disabled by default on ESXi.

Manage → Services → TSM-SSH → Start.
Actions → Policy → Start and stop with host (so SSH persists across reboots).

If SSH stays disabled, requestors can still use the web UI URL — the SSH command in the checkout output will fail to connect.

Configure Britive

Create a resource type for ESXi, register the host, then attach a JIT permission with the checkout/checkin routines.

1. Create the resource type

Go to Resource Manager → Resource Types → New Resource Type.

Field	Value
Name	`ESXi`
Description	`Standalone VMware ESXi host`

Add parameters:

Parameter	Type	Required
`hostname`	string	Yes
`service_account`	string	Yes
`service_account_password`	password	Yes
`verify_tls`	string	No

main.tf

resource "britive_resource_manager_resource_type" "esxi" {
  name        = "ESXi"
  description = "Standalone VMware ESXi host"

  parameters {
    param_name   = "hostname"
    param_type   = "string"
    is_mandatory = true
  }
  parameters {
    param_name   = "service_account"
    param_type   = "string"
    is_mandatory = true
  }
  parameters {
    param_name   = "service_account_password"
    param_type   = "password"
    is_mandatory = true
  }
  parameters {
    param_name   = "verify_tls"
    param_type   = "string"
    is_mandatory = false
  }
}

2. Add the permission with checkout/checkin routines

Clone the reference scripts and register them as a Resource Type Permission. Set the script variables to read from the resource type parameters and the per-checkout context:

Script variable	Source
`ESXI_HOST`	resource parameter `hostname`
`ESXI_SVC_USER`	resource parameter `service_account`
`ESXI_SVC_PASSWORD`	resource parameter `service_account_password` (sensitive)
`ESXI_VERIFY_TLS`	resource parameter `verify_tls` (default `false`)
`BRITIVE_USER_EMAIL`	injected by Britive at checkout/checkin

git clone https://github.com/britive/access-broker-examples.git
cd access-broker-examples/VMware/ESXi/permissions/temp-local-admin
# checkout.py and checkin.py — register these with your Britive Resource Type Permission

In the Britive console: Resource Manager → Resource Types → ESXi → Permissions → New Permission — paste the script bodies or reference the files on the broker host, mark ESXI_SVC_PASSWORD as sensitive, and add a response template that returns access_url, ssh_command, username, password.

3. Register your ESXi host as a resource

In the console: Resource Manager → Resources → New Resource — pick the ESXi resource type, set hostname, service_account, service_account_password, and attach the broker pool that has network access to the host.

4. Create a profile and policy

Build a Resource Manager profile that grants the new permission and a policy that controls who can check it out. For the full profile/policy walkthrough, see Britive Resource Manager profiles.

Verify

Check out the profile

In the Britive console, go to My Access, find the new ESXi profile, click Check Out.

Expected response:

{
  "status": "checked_out",
  "target_host": "<esxi-host>",
  "access_url": "https://<esxi-host>/ui",
  "ssh_command": "ssh <jit-name>@<esxi-host>",
  "username": "<jit-name>",
  "password": "<ephemeral-secret>"
}

Sign in to the host

Open access_url in a browser and sign in with the returned username / password. You should land in the ESXi Host Client with full administrator visibility.

If SSH is enabled on the host, the ssh_command should also connect with the same credentials.

Confirm the account exists on the host

Sign in to the host as root separately and go to Manage → Security & users → Users — confirm the JIT account is present with the Administrator role at the root.

Check in

Return to My Access and click Check In.

Re-open the host’s user list — the JIT account should be gone, and the role binding removed.

Troubleshoot

Symptom	Cause	Fix
Checkout fails with `NoPermission`	Service account does not have `Host.Local.CreateUser` or `Authorization.ModifyPermissions`	Re-assign the Administrator role (or the custom role) at the root with Propagate to children
Checkout fails with a SOAP fault about licensing	Free / unlicensed ESXi blocks write API calls	Apply a vSphere Standard (or higher) license on the host
Checkout fails with `InvalidArgument` on `UpdateUser`	New ESXi password complexity rule rejected the generated secret	ESXi enforces complexity through PAM — adjust the generator in `checkout.py` or relax the host’s PAM rules
`ssh_command` connects but prompt rejects credentials	Host’s SSH service is disabled	Manage → Services → TSM-SSH → Start, or accept that requestors will use the web UI only
Checkin says “revoked” but the account is still on the host	Faults of type `NotFound` are treated as success; an unexpected fault may have left state behind	Re-run checkin manually with the same `BRITIVE_USER_EMAIL` — the script is idempotent
TLS handshake failure from the broker	Host uses a self-signed cert and `ESXI_VERIFY_TLS=true`	Either install a trusted cert on the host or leave `ESXI_VERIFY_TLS=false` (default)

Next Steps

Rotate Local Accounts — rotate the secret of an existing local account on the host
Scan Local Accounts — keep Britive’s identity inventory in sync with the host
VMware vCenter — JIT role grant for vCenter-managed hosts

Last updated on July 8, 2026

Rotate Local Accounts