Getting Started — JIT vCenter Admin

Overview

This guide configures the JIT vCenter Admin access pattern. On checkout, the broker grants the Administrator role at the vCenter root folder (group-d1) to the requestor’s existing SSO/AD principal. On checkin, the role binding is removed. The requestor signs in to vCenter with their usual identity — no ephemeral credentials are returned.

Reference scripts: britive/access-broker-examples/VMware/vCenter/permissions/temp-vcenter-admin/.

Before You Begin

A Britive tenant with administrator access.
A VMware vCenter Server (tested on 8.0).
The Britive user’s email maps to a recognized vCenter principal. Confirm by signing in to vCenter manually as the requestor — if that works, the role-grant call will accept the same principal.
A Britive Access Broker already deployed and connected to your tenant, with:
- python3 3.8+ (standard library only)
- Outbound TCP 443 to vCenter

How It Works

    sequenceDiagram
    actor User
    participant Britive
    participant Broker
    participant vCenter

    User->>Britive: Request JIT access
    Britive->>Britive: Policy evaluation (approvals, IP, time, ITSM ticket)
    Britive->>Broker: Checkout — run checkout.py
    Broker->>vCenter: SOAP POST to /sdk — Login on SessionManager (service account)
    Broker->>vCenter: SetEntityPermissions on AuthorizationManager (principal=requestor, entity=group-d1, role=-1, propagate=true)
    Broker-->>User: vCenter UI URL, elevated principal, role id, entity MOID
    User->>vCenter: Sign in to vCenter UI with usual identity

    Note over User,vCenter: Checkin (manual or expiry)
    Britive->>Broker: Checkin — run checkin.py
    Broker->>vCenter: SOAP POST to /sdk — RemoveEntityPermission for the principal at the same entity

Configure vCenter

Create the service account

In the vCenter UI: Administration → Single Sign On → Users and Groups.

Select the vsphere.local domain.
Create the service account — e.g. britive-svc — with a strong password. The full username is britive-svc@vsphere.local.

Grant the service account permission to manage role bindings

In Administration → Access Control → Global Permissions:

+ Add → select britive-svc@vsphere.local.
Assign a role with at minimum Permissions.ModifyPermissions. The built-in Administrator role works; for least-privilege, create a custom role with only that single privilege.
Set the scope to the entity tree the broker will manage role bindings on (typically the root, with Propagate to children checked).

Confirm the requestor’s principal format

If vCenter is federated with AD / LDAP / OIDC, the Britive user’s email must map to a recognized principal. Test by signing in to vCenter manually as the requestor.

Email / UPN format (jane.doe@example.com): default behavior — Britive passes the email through.
AD downlevel logon (EXAMPLE\jane.doe): set the VCENTER_PRINCIPAL resource parameter to the downlevel format. The script will use it instead of BRITIVE_USER_EMAIL.

Configure Britive

1. Create the resource type

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

Field	Value
Name	`vCenter`
Description	`VMware vCenter Server`

Add parameters:

Parameter	Type	Required	Notes
`hostname`	string	Yes	vCenter FQDN or IP
`service_account`	string	Yes	e.g. `britive-svc@vsphere.local`
`service_account_password`	password	Yes
`principal_override`	string	No	Set for AD downlevel formats
`role_id`	string	No	Default `-1` (Administrator)
`root_moid`	string	No	Default `group-d1` (vCenter root)
`propagate`	string	No	Default `true`
`verify_tls`	string	No	Default `false`

main.tf

resource "britive_resource_manager_resource_type" "vcenter" {
  name        = "vCenter"
  description = "VMware vCenter Server"

  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   = "principal_override"
    param_type   = "string"
    is_mandatory = false
  }
  parameters {
    param_name   = "role_id"
    param_type   = "string"
    is_mandatory = false
  }
  parameters {
    param_name   = "root_moid"
    param_type   = "string"
    is_mandatory = false
  }
}

2. Register the checkout/checkin routines

Script variable	Source
`VCENTER_HOST`	resource parameter `hostname`
`VCENTER_SVC_USER`	resource parameter `service_account`
`VCENTER_SVC_PASSWORD`	resource parameter `service_account_password` (sensitive)
`VCENTER_PRINCIPAL`	resource parameter `principal_override` (optional)
`VCENTER_ROLE_ID`	resource parameter `role_id` (default `-1`)
`VCENTER_ROOT_MOID`	resource parameter `root_moid` (default `group-d1`)
`VCENTER_PROPAGATE`	resource parameter `propagate` (default `true`)
`VCENTER_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/vCenter/permissions/temp-vcenter-admin
# checkout.py and checkin.py — register these with your Britive Resource Type Permission

Mark VCENTER_SVC_PASSWORD as sensitive and add a response template returning access_url, principal, role_id, entity.

3. Register vCenter as a resource

In the console: Resource Manager → Resources → New Resource — pick the vCenter resource type, set hostname, service_account, service_account_password, attach the broker pool, save.

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 My Access, find the vCenter profile, click Check Out.

Expected response:

{
  "status": "checked_out",
  "target_host": "<vcenter>",
  "access_url": "https://<vcenter>/ui",
  "principal": "<requestor-principal>",
  "role_id": -1,
  "entity": "group-d1"
}

Sign in to vCenter

Open access_url and sign in with your usual identity (the same one you use day-to-day). You should land in the vSphere Client with full Administrator visibility.

Confirm the role binding

Sign in to vCenter separately as the service account. Go to Administration → Access Control → Global Permissions — the requestor’s principal should show the Administrator role.

Check in

Return to My Access and click Check In.

Re-open Global Permissions — the requestor’s role binding should be gone.

Troubleshoot

Symptom	Cause	Fix
Checkout fails with `NoPermission`	Service account lacks `Permissions.ModifyPermissions` at the target entity	Re-assign at Global Permissions with Propagate to children
Checkout succeeds but requestor can’t sign in to vCenter	Principal format mismatch — vCenter doesn’t recognize the email	Confirm the principal by signing in manually; if downlevel format needed, set `principal_override` to `DOMAIN\user`
Checkout fails with `InvalidArgument` on `SetEntityPermissions`	`VCENTER_ROOT_MOID` doesn’t exist in this inventory	Confirm the MOID — `group-d1` for vCenter root, or a specific datacenter/cluster MOID for narrower scoping
Checkin says “revoked” but requestor still has access	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	vCenter uses the built-in self-signed cert and `verify_tls=true`	Either install a trusted cert or leave `verify_tls=false` (default)

Next Steps

VMware ESXi — standalone hypervisor JIT (different identity model)
Scope role grants to a specific datacenter or cluster by setting root_moid to the entity’s MOID
Substitute a custom least-privilege role for Administrator by setting role_id to the custom role’s ID

Last updated on July 8, 2026