6.1 vCenter Single Sign-On (SSO) & Identity Sources

6.1 vCenter Single Sign-On (SSO) & Identity Sources

In modern enterprise virtualization, identity management and access control form the primary defensive perimeter for the software-defined data center. VMware vCenter Server relies on vCenter Single Sign-On (SSO) as its centralized authentication broker. SSO abstracts authentication mechanisms away from individual vSphere management components, providing a unified security architecture that validates users across heterogeneous directories, issues secure cryptographic session tokens, and establishes trusted federation with enterprise identity providers.

vCenter Single Sign-On (SSO) Architecture & Mechanics

vCenter Single Sign-On is an integrated security service executing within the vCenter Server Appliance (vCSA). Rather than having vCenter Server (vpxd), Content Libraries, and administrative plug-ins directly authenticate credentials against Active Directory or local operating systems, all authentication requests are mediated by SSO.

+-----------------------------------------------------------------------------------+
| vCenter Single Sign-On (SSO) Architectural Subsystems                             |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Security Token Service (STS)                                                |
|  | - Ingests user credentials / PKI certificates / OIDC claims                 |
|  | - Validates principals against configured Identity Sources                  |
|  | - Generates cryptographically signed SAML 2.0 authorization tokens         |
|  | - Token lifetimes and clock tolerance set by the SSO token policy           |
|  +-----------------------------------------------------------------------------+  |
|                                          ^                                        |
|                                          |                                        |
|  +---------------------------+-----------+---------------+---------------------+  |
|  | Identity Management (IdM) | VMware Directory Service  | Lookup Service      |  |
|  | - Manages directory realm |   (vmdir)                 | - Service discovery |  |
|  |   mappings and connector  | - Replicated LDAP-based   | - Registers vCenter |  |
|  |   configurations          |   multimaster directory   |   endpoints & URIs  |  |
|  +---------------------------+---------------------------+---------------------+  |
+-----------------------------------------------------------------------------------+

The Security Token Service (STS)

The core engine inside vCenter Single Sign-On is the Security Token Service (STS). STS is an authentication service that generates, signs, and validates Security Assertion Markup Language (SAML) 2.0 tokens:

1. Credential Ingestion: When a client (such as the vSphere Client, PowerCLI, or an API automation script) initiates a session, it transmits credentials (username/password, smart card X.509 certificate, or OIDC authorization code) to the STS endpoint via HTTPS (port 443).
2. Authentication Validation: The STS queries the configured Identity Management (IdM) service to locate the principal across connected directory sources and verifies the credential against the directory.
3. SAML 2.0 Token Issuance: Upon successful verification, the STS generates a SAML 2.0 token containing the user's identity, group memberships, and a validity window governed by the SSO token policy (clock tolerance, renewal and delegation counts, and maximum bearer and holder-of-key token lifetimes). The STS signs this token using its private STS Signing Certificate.
4. Service Presentation: The client presents this signed SAML token to vCenter Server services (vpxd). Because vpxd trusts the public certificate of the STS, it accepts the token, determines the user's mapped Role-Based Access Control (RBAC) permissions, and grants access without handling the user's raw password.

Supported Identity Source Types & Modern Architecture

vCenter Server supports multiple identity source types to integrate with enterprise authentication backends. Administrators configure identity sources in the vSphere Client under Administration > Single Sign-On > Configuration > Identity Provider.

1. Active Directory over LDAPS (Lightweight Directory Access Protocol over SSL/TLS)

Active Directory over LDAPS is the standard, enterprise-hardened method for integrating Microsoft Active Directory with vCenter Server:

• Protocols and Ports: Communicates with Active Directory Domain Controllers over TCP port 636 (LDAPS) or TCP port 3269 (Global Catalog over SSL). The same identity source type can also use plain LDAP on 389 or 3268, but LDAPS is strongly recommended.
• Certificate Requirements: Establishing an LDAPS connection requires exporting the Root and Intermediate Certificate Authority (CA) certificates that issued the Active Directory Domain Controller's server certificates. These PEM-encoded certificates must be uploaded to vCenter Server during identity source creation to establish a cryptographic trust chain.
• Connection Modes: Administrators can configure connections to specific Domain Controllers by fully qualified domain name (FQDN) or IP address, or allow vCenter to discover domain controllers dynamically using DNS SRV records (_ldap._tcp.dc._msdcs.<domain>).
• Base Distinguished Names (DNs): Requires entering the User Base DN (e.g., cn=Users,dc=corp,dc=local) and Group Base DN to scope directory search queries and optimize authentication performance.

2. Active Directory (Integrated Windows Authentication - IWA) — Deprecated Status

Historically, vSphere utilized Integrated Windows Authentication (IWA) to join the vCenter Server Appliance directly to an Active Directory domain via Kerberos and SMB:

• Deprecation Status: The vSphere 8.0 release notes deprecate IWA because of performance issues with IWA-based authentication, and recommend AD over LDAP or AD FS instead.
• Operational Drawbacks: IWA requires joining the vCenter appliance to the domain as a computer account and depends on domain-join health. LDAPS and federation avoid the domain join entirely.
• Migration Requirement: Production enterprise environments must transition from IWA to Active Directory over LDAPS or Identity Provider Federation (OIDC).

3. Identity Provider Federation (AD FS, Okta, Microsoft Entra ID, PingFederate)

With identity provider federation, vCenter hands authentication to an external identity provider using OAuth 2.0 and OpenID Connect, instead of acting as an LDAP client:

• Supported Providers: AD FS (vSphere 7.0 and later, federated directly), Okta (8.0 Update 1), Microsoft Entra ID, formerly Azure AD (8.0 Update 2), and PingFederate (8.0 Update 3). Okta, Entra ID, and PingFederate connect through VMware Identity Broker, a built-in container in vCenter, and use SCIM to provision users and groups into vCenter.
• One External Provider: vCenter supports the built-in vsphere.local identity source plus one external identity provider at a time.
• Authentication Flow: When an administrator accesses the vSphere Client, vCenter redirects the browser to the enterprise IdP sign-in portal. The user authenticates directly against the IdP, fulfilling any enterprise security requirements.
• Enterprise Security Benefits:
  • Hardware-Backed MFA: Directly supports FIDO2/WebAuthn hardware security keys, mobile push authenticators (e.g., Microsoft Authenticator, Okta Verify), and time-based one-time passwords (TOTP).
  • Conditional Access Policies: Enforces IP geofencing, compliant device state checks, and risk-based sign-in evaluations before the user is permitted access to vCenter.
  • Zero Password Exposure: vCenter never receives, processes, or stores corporate directory passwords.

Configuring AD FS Federation (Objective 4.4.1)

The blueprint's identity federation objectives, and one of the official sample questions, focus on AD FS, the original federation option (vSphere 7.0 and later). The workflow has two halves:

1. In AD FS: Create an application group for vCenter containing a server application with the vCenter redirect URIs, plus a web API. The server application gives you a Client Identifier and a Shared Secret.
2. In the vSphere Client: Go to Administration > Single Sign On > Configuration > Identity Provider, choose Change Identity Provider, and select Microsoft ADFS. Enter:
   • the Client Identifier of the application group,
   • the Shared Secret of the application group,
   • the OpenID Address (the AD FS OpenID Connect discovery endpoint, https://<adfs-fqdn>/adfs/.well-known/openid-configuration),
   • plus Active Directory over LDAP details (base DNs, bind account, and LDAP server URL) so vCenter can look up users and groups for permissions.
3. Assign permissions to the federated users or groups, then test a login. Browser sign-ins are redirected to AD FS, and administrator@vsphere.local still works as the local fallback.

In an Enhanced Linked Mode group, federation to Okta, Entra ID, or PingFederate is configured on one vCenter and then activated on the other linked vCenter systems. All of them must run a release that supports the chosen provider.

4. Native vsphere.local Domain and Local OS

• vsphere.local Built-in Domain: Created automatically during vCenter Server Appliance deployment. It is hosted within the local VMware Directory Service (vmdir) database.
• The administrator@vsphere.local Principal: The ultimate super-user account for the SSO domain. It possesses unrevocable administrative rights across SSO configuration, certificate stores, and global permissions.
• Break-Glass Emergency Operational Role: Even when an enterprise utilizes external LDAPS or federated Entra ID, administrator@vsphere.local must be retained as an offline emergency break-glass account. If enterprise network outages, DNS failures, or expired domain controller certificates sever communication with external identity sources, administrators can log in using administrator@vsphere.local to diagnose and restore directory links.

Identity Source Comparison Matrix

Security Policies, Smart Cards & Certificate Requirements

To comply with enterprise security frameworks (such as NIST SP 800-53, CIS Benchmarks, and PCI-DSS), vCenter Single Sign-On provides configurable authentication policies, public key infrastructure (PKI) smart card support, and automated certificate lifecycle monitoring.

Single Sign-On Password & Account Lockout Policies

Administrators configure domain-wide password and lockout parameters under Administration > Single Sign-On > Configuration > Local Accounts:

• Password Expiration: Defaults to 90 days (maximum lifetime). A value of 0 means passwords never expire.
• Password Complexity Rules (installation defaults): Minimum length 8 and maximum length 20 characters, with at least 1 special character, 2 alphabetic characters, 1 uppercase, 1 lowercase, and 1 numeric character. The last 5 passwords cannot be reused.
• Account Lockout Policy:
  • Maximum Failed Attempts: Configurable threshold (default: 5 attempts). If a user enters five consecutive invalid passwords, the account transitions to a locked state.
  • Time Interval Between Failures: The window in which the failures must occur (default: 180 seconds).
  • Unlock Time: How long the account stays locked (default: 300 seconds). If set to 0, an administrator must unlock the account manually.

Smart Card (CAC / PIV) Authentication

vSphere SSO supports certificate-based authentication using physical smart cards, such as U.S. Department of Defense Common Access Cards (CAC) or Personal Identity Verification (PIV) cards:

• Mechanics: The administrator inserts their smart card into a physical reader and navigates to the vSphere Client. The reverse proxy on vCenter prompts the client browser for an X.509 client certificate.
• Certificate Validation: vCenter validates the certificate against imported trusted CA certificates and queries Online Certificate Status Protocol (OCSP) responders or Certificate Revocation Lists (CRLs) to verify the card has not been revoked.
• User Principal Mapping: SSO extracts the User Principal Name (UPN) from the Subject Alternative Name (SAN) field of the certificate and maps it to the corresponding Active Directory or vsphere.local account.

Security Token Service (STS) Certificate Lifecycle

The STS Signing Certificate is a critical cryptographic asset within the VMware Certificate Authority (VMCA) store. It signs every SAML token issued to administrators and internal services:

• Expiration Impact: If the STS signing certificate expires, the STS stops issuing valid tokens and users cannot log in to the vSphere Client.
• Auto-Renewal in vSphere 8: In vSphere 8.0 and later, vCenter SSO automatically renews a VMCA-generated STS signing certificate before it expires and before the 90-day expiration alarm would fire. If auto-renewal fails, an error is logged and you can refresh the STS certificate manually from the vSphere Client. Custom (non-VMCA) STS certificates must be replaced manually.

Realistic Troubleshooting & Exam Traps

Scenario 1: Active Directory LDAPS Connection Failure after Domain Controller Certificate Renewal

Problem: Following an annual enterprise PKI certificate rotation on corporate domain controllers, all domain users are unable to authenticate to the vSphere Client, receiving the error: Cannot connect to the LDAP server. Local administrator@vsphere.local authentication continues to function normally.

Root Cause Analysis:

• When Active Directory over LDAPS is established, vCenter stores the Certificate Authority (CA) chain that signed the domain controller's server certificate.
• The enterprise PKI team renewed the domain controller certificates using a newly minted Intermediate CA that was not part of the original CA bundle uploaded to vCenter Server.
• When vCenter attempts the TLS handshake to the domain controller on port 636, the Java cryptographic trust store (cacerts) inside vCenter rejects the connection due to an untrusted certificate chain (PKIX path building failed).

Resolution:

1. Log into the vSphere Client using the emergency break-glass account administrator@vsphere.local.
2. Navigate to Administration > Single Sign-On > Configuration > Identity Provider > Identity Sources.
3. Select the Active Directory LDAPS identity source and click Edit.
4. Upload the updated PEM certificate chain containing the new Intermediate and Root CA certificates.
5. Click Save. Verify that connection testing succeeds against all configured domain controller FQDNs.

Scenario 2: OIDC Federation Token Rejection Due to NTP Clock Skew

Problem: An organization enables Identity Provider Federation with Microsoft Entra ID. When administrators log in, they successfully authenticate at the Microsoft sign-in page and complete MFA, but upon redirection back to vCenter, the login fails with an error that the token is not yet valid or has expired.

Root Cause Analysis:

• Cryptographic tokens generated by OpenID Connect and SAML 2.0 include nbf (not before) and exp (expiration) timestamp claims.
• If the vCenter Server Appliance clock drifts beyond the allowed clock tolerance relative to the identity provider, vCenter rejects tokens as not yet valid or already expired.

Resolution:

1. In the vCenter Server Management Interface (VAMI, https://<vcenter-fqdn>:5480), navigate to Time.
2. Ensure Network Time Protocol (NTP) synchronization is enabled and pointing to reliable external NTP servers (e.g., pool.ntp.org or enterprise Stratum 1 clocks).
3. Synchronize all underlying ESXi hosts to the exact same NTP servers via host profiles or vSphere Lifecycle Manager.

Exam Trap: Look out for questions suggesting that Active Directory Integrated Windows Authentication (IWA) is the recommended choice for new vSphere 8 deployments. IWA is deprecated. Use Active Directory over LDAP (preferably LDAPS on port 636) or identity provider federation such as AD FS, Okta, Microsoft Entra ID, or PingFederate.