VMware ESXi and vSphere Cluster Management

What Is vCenter Single Sign-On (SSO)?

Learn how vCenter Single Sign-On authenticates vSphere users, issues security tokens, connects identity sources, and works with vCenter permissions.

vCenter Single Sign-On (SSO) is the centralized authentication service used by vSphere management components. It verifies a user or service identity and issues a security token that trusted vSphere services can accept.

SSO provides a single-login experience. After a user authenticates, the user can access authorized integrated services without repeatedly submitting the original password. SSO does not decide everything the user may do: authentication verifies identity, while authorization determines which inventory objects and actions are permitted.

What vCenter SSO Does

In a vSphere environment, SSO acts as a trusted identity broker between users, identity sources, and management services. A user signs in through a client such as the historical vSphere Web Client. SSO validates the credentials against the selected identity source and returns a time-limited token after successful authentication.

The client then presents the token to a participating service, such as vCenter Server. The service validates the token and performs its own authorization checks. The user's password does not need to be sent separately to every participating service.

Authentication versus authorization

Function: Authentication

Performed by: SSO and the configured identity source

Purpose: Verify that an account is who it claims to be

Example outcome: SSO accepts valid credentials and issues a token

Function: Token issuance

Performed by: SSO

Purpose: Create a signed, time-limited assertion for trusted services

Example outcome: The client receives a usable session token

Function: Authorization

Performed by: vCenter Server or another participating service

Purpose: Determine which actions and inventory objects are allowed

Example outcome: A user can manage a cluster but cannot alter SSO settings

A valid SSO token never bypasses authorization. A user can authenticate successfully and still have no access to vCenter inventory if no appropriate role or permission has been assigned.

Why vSphere Uses SSO

  • It simplifies access to several management services through one identity and sign-in process.
  • It provides a trusted authentication mechanism for communication among integrated vSphere products.
  • It reduces duplicated account administration when an external directory is used.
  • It uses security tokens instead of requiring the user's password to be submitted to every participating service.

For example, an administrator can authenticate with an Active Directory account once and then access authorized vCenter functions through the client. The directory remains the source of identity, while vCenter permissions control the administrator's effective access.

SSO Components and Integrated Services

vCenter Server is the primary consumer most administrators associate with SSO. It manages ESXi hosts, virtual machines, inventory, and permissions. SSO can also support other management components in the historical vSphere ecosystem, where the exact integration depends on product and vSphere versions.

  • vSphere Web Client: A historical browser-based administrative client that submits sign-in requests to SSO.
  • vCenter Orchestrator (vCO): A historical workflow automation component that can use SSO integration.
  • vCloud Networking and Security (vCNS): A historical networking and security product referenced in older vSphere integrations.
  • vCloud Director (vCD): A cloud management product that can participate in an SSO-enabled environment.

Do not assume that every product supports every SSO arrangement. Product integration, supported identity sources, token behavior, and administration interfaces depend on the deployed versions. Check the compatibility and installation documentation for the specific environment.

How the SSO Authentication Process Works

The following sequence describes the process at a high level:

  1. A user opens the vSphere Web Client or the management client appropriate to the installed release.
  2. The client submits the user's credentials and selected identity domain or source to SSO.
  3. SSO selects or contacts the appropriate authentication source, such as the local SSO domain, Active Directory, or OpenLDAP.
  4. The identity source validates the account and password.
  5. If authentication succeeds, SSO issues a signed, time-limited security token and returns it to the client.
  6. The client presents the token to a trusted service such as vCenter Server instead of repeatedly submitting the original password.
  7. vCenter Server evaluates the user's roles, permissions, group membership, inventory scope, and requested action.
  8. Access is granted only when both authentication and authorization succeed. If authentication fails, SSO issues no usable token and access is denied.

Step: User starts sign-in in the client

Actor: User and management client

Action: The user enters an account, password, and usually an identity domain

Result: The client sends a sign-in request

Step: Client sends credentials to SSO

Actor: vSphere client

Action: The client submits the credentials to the SSO service

Result: SSO begins identity validation

Step: SSO validates against an identity source

Actor: SSO and local or external identity source

Action: SSO contacts the selected repository or provider

Result: The account is accepted or rejected

Step: SSO returns a token

Actor: SSO

Action: SSO issues a signed token after successful authentication

Result: The client has a time-limited assertion

Step: Client presents the token

Actor: Client and trusted vSphere service

Action: The client presents the token to vCenter Server or another participating service

Result: The service validates the token

Step: Service evaluates permissions

Actor: vCenter Server or participating service

Action: The service checks roles, groups, privileges, and inventory scope

Result: The requested operation is allowed or denied

Identity Sources and User Repositories

An identity source is a configured user repository or authentication provider that SSO uses to validate an account. Identity sources may be local to the SSO domain or provided by an external directory.

Identity source: Local SSO domain

Typical use: Built-in administrative or service-oriented accounts maintained by SSO

Key planning considerations: Protect privileged accounts, document the SSO domain, and limit local accounts to appropriate purposes

Identity source: Active Directory

Typical use: Employee, administrator, and group-based authentication

Key planning considerations: DNS, domain reachability, time synchronization, trusted-domain design, bind or service account requirements where relevant, and group membership

Identity source: OpenLDAP

Typical use: Authentication against an LDAP-based directory

Key planning considerations: LDAP server reachability, base DN, bind account, search and group settings, TLS trust, DNS, and synchronized time

A deployment can have multiple identity sources. When signing in, a user may need to select or specify the identity domain containing the account. Choosing the wrong source can produce an unknown-user or invalid-credential result even when the password is correct.

Planning checklist

  • Confirm that vCenter and related SSO components can resolve directory names through DNS.
  • Verify network routes, firewall rules, and directory ports.
  • Maintain reliable time synchronization between clients, vCenter, directory servers, and other participating systems.
  • Use a dedicated service or bind account when the directory integration requires one, and protect it from unnecessary privileges.
  • Plan trusted-domain relationships if accounts or groups come from multiple domains.
  • Confirm that required group membership is present and can be resolved by the identity source.
  • Plan for the administrative impact of an unavailable directory service.

Tokens and Trust Relationships

An SSO token is a signed, time-limited assertion that an authenticated identity can present to a trusted service. It communicates that authentication has already occurred without exposing the original password to each service.

Token acceptance depends on trust relationships, valid certificates, and compatible token information. Token lifetime is intentionally limited and varies with the product release and configured policies. A session may need to be renewed when a token expires.

Certificate expiration, an untrusted certificate chain, incorrect system time, or unavailable SSO services can prevent a service from accepting an otherwise expected token. Token validity also does not grant privileges; the receiving service still checks authorization.

Configuring and Administering SSO

SSO settings are administered through the vSphere management interface appropriate to the deployed version. Legacy deployments commonly used the vSphere Web Client. Newer deployments generally use the vSphere Client and an appliance or embedded-services administration model.

Typical administrator tasks

  • Add or edit identity sources.
  • Set the default authentication domain.
  • Review and manage local SSO users.
  • Assign vCenter roles and permissions to users or groups.
  • Review certificates, trust relationships, token policies, and service health where supported by the release.

Adding an identity source does not automatically grant vCenter access. After the source is configured, a user or group must still receive a vCenter permission at the correct inventory scope. Use directory groups instead of assigning permissions individually whenever possible.

Workflow: Add an external identity source

  1. Open the vSphere administration interface for the installed version.
  2. Navigate to the SSO or identity-source administration area.
  3. Choose the source type, such as Active Directory or OpenLDAP.
  4. Enter the required domain, LDAP, connection, and credential information.
  5. Validate connectivity and save the configuration.
  6. Test authentication with a non-privileged account before assigning elevated permissions.

Workflow: Grant vCenter access to a directory group

  1. Confirm that the configured identity source can resolve the directory group.
  2. Add the group to vCenter permissions at the appropriate inventory scope.
  3. Assign the least-privileged role that meets the group's responsibilities. See assigning permissions for the general permission model.
  4. Sign in as a test group member and verify both allowed and denied actions.

SSO and vCenter Installation

In historical vSphere releases, SSO was a required platform service associated with vCenter Server installation. It could need to be installed or selected before the vCenter Server component. This is why older installation procedures may describe separate SSO, inventory, and vCenter installation stages. A related legacy workflow is covered in vCenter Server Simple Install.

Deployment architecture changed across vSphere releases. Later designs introduced the Platform Services Controller (PSC), which grouped infrastructure services including SSO. Newer vCenter Server Appliance deployments include these functions within the appliance or use embedded services, depending on the version and topology.

Follow the installation workflow and compatibility documentation for the exact vCenter release. Do not assume that legacy component ordering or external-service layouts apply to a newer appliance deployment. For architecture background, see deployment modes in vCenter SSO.

Security and Operational Practices

  • Use secure directory integration and supported certificates.
  • Assign least-privilege roles and prefer group-based access control.
  • Protect privileged SSO, directory, bind, and service accounts.
  • Maintain correct DNS resolution and time synchronization.
  • Plan identity-source availability and a documented response for directory outages.
  • Maintain trusted certificate chains where token or service validation requires them.
  • Test access with ordinary accounts before granting administrative roles.
  • Review permissions at the correct inventory level and remove stale group memberships.

Practical Examples

Administrator signs in using Active Directory

  1. An administrator opens the vSphere Web Client and enters a domain account.
  2. SSO validates the account against the configured Active Directory identity source.
  3. After successful validation, SSO issues a token to the client.
  4. The client presents the token to vCenter Server.
  5. vCenter checks permissions assigned to the administrator or the administrator's directory groups.
  6. Management actions are available only when the required privileges exist.

Automation user from a local SSO domain

A service-oriented local SSO account authenticates to SSO and receives a token. An automation component uses that token to access authorized service endpoints. The account should have only the inventory permissions and actions required by the automation task.

Multiple identity sources

An organization might configure an Active Directory domain for employees and an OpenLDAP repository for a separate operations team. Each person signs in through the source containing the account. vCenter permissions are assigned to the corresponding users or groups; authentication through either source does not automatically grant access.

Troubleshooting SSO

User authenticates but cannot see or manage expected inventory

  • Likely causes: No vCenter permission exists, the permission is at the wrong inventory scope, inheritance is not configured as intended, or group membership is missing or unresolved.
  • Checks: Verify the identity source recognizes the user and groups. Review vCenter roles and permissions at the relevant object. Confirm inheritance and propagation settings where applicable.

Active Directory or LDAP authentication fails

  • Likely causes: Incorrect identity-source settings, failed DNS resolution, blocked network traffic, invalid or expired bind credentials, or incorrect time.
  • Checks: Validate domain or LDAP server names, ports, base DN, and bind details. Test name resolution and reachability from the relevant vCenter or SSO system. Verify directory account status and synchronized time.

The client repeatedly requests credentials or reports token errors

  • Likely causes: An SSO service problem, certificate or trust issue, system-time mismatch, or expired session token.
  • Checks: Confirm SSO-related services are running. Review certificate validity and trust configuration. Check time on clients, vCenter, and directory infrastructure. Sign out, begin a new session, and inspect relevant service logs.

An external identity source cannot be added

  • Likely causes: The directory configuration is unsupported for the vSphere version, LDAP parameters are incorrect, the SSL/TLS chain is untrusted, or the bind account lacks required query privileges.
  • Checks: Verify version-specific support. Validate the LDAP URL, search base, group lookup behavior, and certificate chain. Confirm that the bind account can perform the required directory queries.

Key Exam and Administration Notes

  • SSO performs authentication; vCenter roles and permissions perform authorization.
  • An identity source is the repository SSO uses to validate accounts.
  • Local SSO users and external directory users are different account types.
  • Multiple identity sources can be configured, so the correct identity domain matters during sign-in.
  • Successful authentication produces a token, but a token alone does not grant vCenter privileges.
  • Legacy vSphere installations may have required SSO as a separate or earlier installation component; newer appliance architectures differ.
  • DNS, time synchronization, certificates, directory reachability, and group membership are frequent causes of SSO problems.