9.1 vCenter Single Sign-On (SSO), Identity Federation & RBAC

9.1 vCenter Single Sign-On (SSO), Identity Federation & RBAC

Securing a VMware vSphere Foundation (VVF) 9.0 environment begins with robust identity governance, access boundary definition, and granular privilege enforcement. Virtualization administrators oversee physical compute, software-defined storage, network topologies, and business-critical tenant virtual machines. Granting excessive or unmonitored privileges introduces catastrophic operational and security vulnerabilities. To establish a defense-in-depth posture, vSphere decouples identity verification from access rights through vCenter Single Sign-On (SSO) and Role-Based Access Control (RBAC).

---

vCenter Single Sign-On (SSO) Architecture & Mechanics

vCenter Single Sign-On operates as an enterprise authentication broker embedded directly within the vCenter Server Appliance (VCSA). SSO brokers supported vCenter-integrated authentication. Direct ESX access, guest accounts and external product role assignments retain their own authorization/configuration requirements.

Authentication vs. Authorization

A foundational principle tested on the examination is the operational separation between authentication and authorization:

• Authentication (AuthN): The process of verifying who the principal is. SSO handles authentication by prompting the user for credentials, validating those credentials against a configured identity source, and issuing a cryptographically signed token.
• Authorization (AuthZ): The process of determining what actions that authenticated principal is permitted to perform. Authorization is handled locally within vCenter Server by evaluating the user's role assignments against target inventory objects in the permissions database.

The Security Token Service (STS)

The core engine within vCenter Single Sign-On is the Security Token Service (STS). When an administrator or programmatic API client initiates a login session:

1. The user presents authentication credentials (or an external identity assertion) to the STS endpoint.
2. The STS authenticates the identity against the relevant identity provider.
3. Upon successful validation, the STS generates and issues a cryptographically signed Security Assertion Markup Language (SAML) 2.0 token.
4. The client uses this SAML token to interact with various vCenter services (such as vpxd, Content Libraries, or the vSphere Lifecycle Manager) without ever transmitting or storing the user's cleartext password in subsequent requests.

The vsphere.local Default Identity Domain

During the initial stage of vCenter Server Appliance deployment, the installer prompts for an SSO domain name, which defaults to vsphere.local. This internal domain creates an isolated, local directory service:

• administrator@vsphere.local: The built-in superuser account created during installation. This account possesses unrestricted administrative privileges across the entire SSO domain and vCenter inventory. It is utilized to bootstrap initial infrastructure, configure external identity sources, and recover system access during identity provider outages.
• Built-in System Groups: Includes groups such as Administrators, SystemConfiguration.Administrators, and TrustedAdmin used to grant infrastructure-wide authority.
• Password & Lockout Policies: Administrators configure maximum password age, complexity rules, and account lockout thresholds specifically for the vsphere.local domain via Administration > Single Sign-On > Configuration in the vSphere Client.

---

Identity Sources: Modern Federation vs. Legacy Protocols

While the vsphere.local domain is essential for bootstrap operations and break-glass emergencies, production enterprise environments require integrating centralized corporate identity providers.

OpenID Connect (OIDC) Identity Federation

vSphere 9.0 elevates OpenID Connect (OIDC) identity federation as the premier standard for enterprise authentication. Instead of vCenter directly querying a directory via LDAP, vSphere federates trust with an external enterprise Identity Provider (IdP) such as Microsoft Entra ID (formerly Azure AD), Okta, or PingFederate.

When a user logs in via OIDC Federation:

1. The vSphere Client login page displays a button redirecting the browser to the corporate IdP login portal.
2. The user authenticates directly at the enterprise IdP, completing corporate Multi-Factor Authentication (MFA), conditional access evaluations, and biometric checks.
3. The IdP issues a signed JSON Web Token (JWT) ID token and authorization code, redirecting the browser back to the vCenter redirect URI (https://<vcenter-fqdn>/ui/login/oauth2/code/...).
4. vCenter SSO validates the token's cryptographic signature against the IdP's JSON Web Key Set (JWKS) endpoint and extracts the user's identity and group memberships.
5. vCenter's STS issues an internal SAML token, logging the user into the vSphere Client.

For the federated sign-in flow, the external identity provider handles enterprise authentication and its configured MFA policy. vCenter consumes the trusted authentication result and still enforces its own authorization; local and non-federated accounts have separate authentication paths.

Active Directory over LDAPS vs. Removed IWA

For organizations maintaining traditional on-premises Microsoft Active Directory Domain Services (AD DS):

• LDAPS (Active Directory over LDAP over SSL): The current supported standard. Communicates securely over TCP port 636. Administrators must upload the Active Directory Certificate Authority (CA) root and intermediate certificates to vCenter to establish TLS trust, specify primary and secondary Domain Controller endpoints, and configure a dedicated service account for directory binding.
• Integrated Windows Authentication (IWA) Deprecation: Historically, vCenter joined the Active Directory domain directly using machine accounts and Kerberos. VMware removed in vCenter 9.0 IWA due to architectural complexity, tight coupling with SMB/NetBIOS, Kerberos ticket vulnerability risks, and failure modes when domain controllers experience replication delays. Administrators must actively migrate legacy IWA configurations to either OIDC Federation or AD over LDAPS.

---

Role-Based Access Control (RBAC) Architecture

Once a user or group is authenticated by SSO, vCenter's Role-Based Access Control engine determines their authorized operational scope. RBAC relies on three core constructs:

1. Privileges

A privilege is an atomic, granular right to perform a specific action within vCenter Server. vSphere defines hundreds of individual privileges categorized by subsystem, such as:

• VirtualMachine.Interact.PowerOn
• VirtualMachine.Config.AddNewDisk
• Datastore.AllocateSpace
• Network.Assign

Privileges cannot be directly assigned to users or groups. They must be packaged inside a role.

2. Roles

A role is a named administrative container that groups multiple individual privileges together. vSphere categorizes roles into three classes:

• System Roles: Built-in permanent roles that cannot be modified or deleted:
  • Administrator: Grants all privileges across all inventory objects. Users assigned this role can modify permissions, manage certificates, and reconfigure infrastructure.
  • Read-Only: Allows users to view the state and configuration of inventory objects, performance charts, and tasks, but prevents executing any state-changing operations.
  • No Access: Explicitly denies all access to the assigned object. It acts as an access masking mask; objects assigned No Access become invisible to the user in the inventory tree.
• Sample Roles: Preconfigured role templates provided by VMware covering standard operational duties (such as Virtual Machine Power User, Datastore Consumer, or Network Administrator). These can be cloned and customized.
• Custom Roles: User-defined roles created from scratch by administrators to enforce the principle of least privilege for specific organizational teams (e.g., a Backup-Operator role containing only snapshot creation, deletion, and virtual machine query privileges).

3. Permissions

A permission is the binding rule that brings together three components: an Identity Principal (user or group), a Role (privilege bundle), and an Inventory Object (target resource). Each permission includes a boolean Propagate to children flag:

• When set to True, the permission cascades down the entire hierarchy beneath that object.
• When set to False, the permission applies strictly to the selected entity and does not affect child items.

---

Permission Inheritance & Precedence Rules

vSphere inventory is structured as a hierarchical tree: Root Folder > Datacenter > Host/Cluster/Compute Resource > Resource Pool / VM Folder > Virtual Machine (with parallel hierarchies for Datastores and Networks). When a user attempts to execute an action, vCenter evaluates permissions using a strict order of precedence:

Rule 1: Object Proximity (Explicit Beats Inherited)

Permissions defined directly on an inventory object (explicit permissions) always take precedence over permissions inherited from parent objects higher in the tree, regardless of whether the permission is more restrictive or more permissive.

• Scenario: Group Engineers is assigned the Administrator role on Datacenter-01 with propagation enabled. On a specific virtual machine VM-Database inside that Datacenter, the user jdoe (a member of Engineers) is explicitly assigned the Read-Only role. When jdoe accesses VM-Database, the explicit Read-Only assignment wins. jdoe cannot power off or reconfigure that virtual machine.

Rule 2: Principal Specificity (User Beats Group)

If an individual user and a group containing that user are both assigned permissions on the exact same inventory object, the individual user assignment takes precedence over the group assignment.

• Scenario: On Cluster-A, user asmith is assigned Read-Only. On Cluster-A, the group Cloud-Admins (which includes asmith) is assigned Administrator. Because both assignments exist at the exact same level of the hierarchy, asmith receives Read-Only on Cluster-A.

Rule 3: Union of Group Permissions

If a user belongs to multiple groups that are assigned different roles on the exact same inventory object, vCenter grants the union of all privileges across those roles.

• Scenario: User bwhite belongs to Storage-Admins (assigned a role with Datastore privileges) and Network-Admins (assigned a role with Virtual Distributed Switch privileges) on Datacenter-01. bwhite receives the combined privileges of both roles on Datacenter-01.
• No Access is not a universal deny rule across group memberships. At the same object, group privileges combine; a group carrying no privileges does not cancel another group's grant. A direct user assignment can override the group result. Test with the intended principal and inspect inherited and explicit permissions.

Rule 4: Child Masking with 'No Access'

To hide sensitive virtual machines or resource pools from a department that otherwise possesses broad cluster access, an administrator assigns the No Access role directly to that child object with propagation enabled. The child object disappears from the user's inventory view entirely.

---

Global Permissions vs. Object-Level Permissions

vSphere differentiates between standard object-level permissions and Global Permissions:

Global Permissions are essential for assigning infrastructure-wide privileges, such as granting a centralized security auditing team read-only visibility across all linked vCenter servers and content catalogs with a single configuration entry.

Source Notes

The version-9 identity change is documented in Broadcom KB 314324. Checked October 18, 2026.

Review Takeaways

• vCenter Single Sign-On (SSO) centralizes authentication via the Security Token Service (STS), which issues cryptographically signed SAML 2.0 tokens for internal and external service consumption.
• The default local identity domain is vsphere.local, with administrator@vsphere.local serving as the bootstrap superuser for initial deployment and identity configuration.
• vCenter 9.0 removes IWA and direct AD domain join; use a supported federated provider or AD over LDAPS.
• Role-Based Access Control (RBAC) combines a principal (user or group), a role (collection of granular privileges), and an inventory object, with an optional propagation flag.
• In permission resolution, explicit object permissions override inherited parent permissions, user assignments override group assignments at the same level, and concurrent group memberships evaluate as a union of privileges.