VMware ESXi and vSphere Cluster Management

What Is vCenter Single Sign-On (SSO)?

Learn how vCenter Single Sign-On authenticates vSphere users, integrates with Active Directory and LDAP, issues security tokens, and works with vCenter permissions.

vCenter Single Sign-On (SSO) is the centralized authentication service for a vSphere environment. It verifies a user's identity and issues a security token that trusted VMware services can accept.

SSO lets an administrator sign in through the vSphere Web Client once and then access vCenter Server and eligible integrated VMware management components without repeatedly sending the password. SSO simplifies identity integration, but it does not decide every action a user may perform. That responsibility belongs to roles and permissions.

What vCenter Single Sign-On Does

Authentication is the process of proving who a user is. SSO validates credentials against a configured identity source, such as a local SSO user database, Microsoft Active Directory, or OpenLDAP.

Authorization is the process of deciding what an authenticated identity may access or change. After SSO verifies a user, vCenter Server evaluates the user's assigned roles and permissions. A successful sign-in therefore does not automatically make someone a vSphere administrator.

The main operational benefits are:

• Fewer repeated credential prompts during a management session.
• Centralized integration with enterprise directories.
• Token-based trust between the client, vCenter Server, and supported VMware services.
• Group-based administration instead of maintaining separate accounts in every component.

For a broader overview, see vCenter Single Sign-On (SSO).

Where SSO Fits in vSphere

SSO is a foundational service used by vCenter Server and supported vSphere-related products. The vSphere Web Client authenticates to SSO first. After successful authentication, the client uses the resulting token when communicating with trusted services.

Depending on the vSphere generation and product deployment, examples of SSO consumers include:

• vCenter Server, the central management platform for hosts, virtual machines, inventory, and permissions.
• vCenter Orchestrator, a workflow automation component that can participate in SSO-based authentication.
• vCloud Networking and Security (vCNS), a legacy VMware networking and security component that can integrate with SSO.
• vCloud Director, a cloud-management product that can use SSO integration.

Exact product names, supported integrations, and deployment requirements vary by vSphere release. Always match the SSO and product instructions to the version being installed.

SSO and the vCenter Server Installation Dependency

In the vSphere generation covered here, SSO is required before installing vCenter Server. The relationship can be understood as a simple dependency chain:

1. Prepare identity requirements, including DNS, directory reachability, naming, time synchronization, and any required service or bind credentials.
2. Install and configure SSO.
3. Install vCenter Server and register or connect the other supported components that will trust SSO.
4. Configure identity sources, users or groups, and vCenter permissions.

Later vSphere releases may package or deploy SSO differently. The underlying authentication concepts remain useful, but installation steps and management interfaces can change. Follow documentation for the specific release.

Identity Sources and User Repositories

An identity source is a configured user repository or authentication provider that SSO consults when validating credentials. Identity sources determine where accounts and groups are maintained; they do not, by themselves, grant access to vCenter inventory.

SSO uses the entered account format and configured identity-source information to route authentication to the appropriate provider. The exact username format depends on the configured domain and vSphere release.

Directory integration allows existing enterprise identities to be used instead of creating separate vSphere-only accounts. Before configuring it, verify:

• DNS resolves the SSO system and directory servers correctly.
• Network paths and required directory ports are available.
• The domain or LDAP naming information is correct.
• Service account or bind credentials are valid when the selected integration requires them.
• Directory connections use appropriate security protections.
• Systems have accurate, synchronized clocks.

The SSO Authentication Workflow

The following sequence shows what happens during a typical vSphere Web Client login.

A failed login can occur at several points. The credentials may be invalid, the identity source may be unavailable, a directory lookup may fail, the token may be invalid or expired, or the target service may have a trust or connectivity problem.

Security Tokens and Trust

A security token is a time-limited credential or assertion issued by SSO after successful authentication. The client presents the token to trusted VMware services instead of submitting the user's password for every request.

A trusted service is a VMware component configured to accept and validate SSO-issued tokens. The trust relationship must exist between the SSO service, the vSphere Web Client, vCenter Server, and any integrated VMware service that is expected to participate.

Token handling has a lifecycle:

1. Issuance: SSO creates a token after the identity source validates the credentials.
2. Use: The client presents the token to trusted services during the session.
3. Expiration: The token becomes invalid after its lifetime ends.
4. Renewal or reauthentication: The client may obtain a renewed token or require the user to sign in again, depending on the product and session state.
5. Invalidation: A token may stop being accepted because of logout, administrative action, trust changes, or other service conditions.

Protect the token and the surrounding trust infrastructure. Important controls include valid certificates, accurate time synchronization, protected SSO administrator credentials, secure directory connections, and least-privilege authorization. Certificate or clock problems can make a valid token appear untrusted or expired.

Configuring and Administering SSO

In the covered environment, SSO configuration is performed through the vSphere Web Client. The broad workflow is:

1. Open the SSO administration area.
2. Add or review a local, Active Directory, or OpenLDAP identity source.
3. Enter the connection details required by the selected source, such as a domain, LDAP endpoint, directory naming information, and bind settings where applicable.
4. Verify the intended default domain or identity source used for authentication.
5. Manage local SSO users and groups when local identities are needed.
6. Identify the directory groups that should administer vSphere.
7. Assign vCenter roles and inventory permissions to those groups.

Identity-source configuration and vCenter inventory permissions are separate tasks. Adding Active Directory does not automatically allow every domain user to view or administer vCenter. A user or group must still be assigned an appropriate role at the correct inventory level.

Assign permissions to groups whenever practical. Group-based assignment reduces administrative overhead, supports staff changes through directory membership, and produces a more consistent permission model than assigning rights individually to many users.

Example: Active Directory-Backed Administrator Login

1. An administrator opens the vSphere Web Client and enters an Active Directory account in the configured account format.
2. The client sends the credentials to SSO.
3. SSO routes the request to the configured Active Directory identity source.
4. Active Directory validates the account and password, subject to directory policies such as lockout or expiration rules.
5. SSO issues a security token after successful validation.
6. The vSphere Web Client presents the token to vCenter Server.
7. vCenter Server finds the user's group memberships and assigned permissions.
8. The administrator can perform only the operations allowed by the applicable vCenter role and inventory permissions.

This example demonstrates the separation between directory authentication and vCenter authorization. Active Directory confirms the identity; vCenter decides what that identity can do.

Example: Local SSO Account

A local SSO account is maintained inside SSO rather than in Active Directory or OpenLDAP. An administrator can use it when an external directory has not yet been configured or is temporarily unavailable.

1. The administrator signs in with the local SSO administrator account.
2. SSO validates the account internally.
3. The administrator configures an external identity source through the vSphere Web Client.
4. The administrator assigns vCenter access to approved directory users or groups.

A protected local account provides an administrative path independent of external directory availability. It should be secured and used according to the organization's recovery and access policies.

One Sign-In Across Trusted Services

In a supported integration, a user signs in through the vSphere Web Client and receives one SSO token. During the session, vCenter Server and eligible integrated VMware services can accept that trusted token. The convenience comes from token-based trust, not from sharing the user's password among services.

What SSO Does Not Do

• SSO does not automatically grant administrative rights.
• Adding a directory as an identity source does not grant every directory user access to vCenter.
• SSO is not the same as logging in to the operating system.
• SSO is not identical to ESXi host authentication.
• SSO is not a universal enterprise sign-in mechanism for unrelated applications.
• Users still need correct permissions within the target vSphere service.

Troubleshooting SSO Access

Domain User Cannot Sign In

Likely causes include an incorrect username or password, an incorrectly configured Active Directory or OpenLDAP identity source, DNS or network failure, an account format that does not identify the intended source, account lockout, account expiration, or directory policy restrictions.

• Confirm the credentials and account status.
• Verify identity-source settings and directory reachability.
• Check DNS name resolution and required network connectivity.
• Confirm time synchronization between relevant systems.
• Test with a known local SSO administrator account. A successful local login helps distinguish external-directory failure from general SSO unavailability.

User Authenticates but Cannot Access Inventory

This usually indicates an authorization problem rather than an authentication problem. The user may have no vCenter role, permissions may be assigned at the wrong inventory level, or group membership may be missing or unrecognized.

• Confirm that SSO can see the user or directory group.
• Review assigned vCenter roles and inventory permissions.
• Check permission inheritance and the user's effective privileges.
• Verify that the user is a member of the intended administrative group.

Integrated Service Rejects the Token

Possible causes include incorrect SSO registration or trust configuration, token expiration, certificate problems, inaccurate clocks, or service connectivity failures.

• Verify the target service's SSO integration and trust configuration.
• Check certificate validity and system clocks.
• Retry the login to obtain a fresh token.
• Review logs for the target service and SSO components.

Exam-Relevant Notes

• SSO performs authentication; roles and permissions perform authorization.
• An identity source is where SSO validates users and groups.
• Active Directory, OpenLDAP, and local SSO users are example identity sources.
• A security token enables trusted services to accept a verified sign-in without repeatedly receiving the user's password.
• Adding an identity source does not automatically grant vCenter access.
• In the covered vSphere generation, SSO is installed or configured as a prerequisite for vCenter Server.
• DNS, certificates, time synchronization, directory reachability, and service trust are essential to reliable token-based authentication.