VMware ESXi and vSphere Cluster Management

vCenter Single Sign-On Identity Sources

Learn how vCenter Server 5.5 SSO identity sources use Active Directory, OpenLDAP, local accounts, and vsphere.local for authentication and domain-based login resolution.

vCenter Single Sign-On (SSO) authenticates users by consulting configured identity sources. An identity source is a directory or account repository that contains users and groups. In vCenter Server 5.5, SSO can use more than one repository, allowing identities from different domains or directory platforms to sign in.

Authentication answers “Who is this user?” Authorization answers “What is this user allowed to do?” An identity source participates in authentication. After authentication, vCenter roles and permissions determine access to inventory objects and operations.

How Identity Sources Relate to Domains

Every configured identity source is associated with a domain. The domain acts as a namespace that tells SSO where a supplied username should be validated.

For example, an Active Directory identity source might be associated with corp.example, while the built-in SSO source uses vsphere.local. A username without a domain qualifier is looked up in the current default identity source. A user from another domain should identify that domain explicitly when signing in.

Supported vCenter Server 5.5 Identity Sources

Identity source type	Supported directory or account type	Web Client name	Domain and quantity behavior	Deployment restrictions	Primary use
Active Directory using Integrated Windows Authentication	Active Directory 2003 and later	Active Directory (Integrated Windows Authentication)	A single AD domain can be selected. It may be a forest root or contain child domains.	Requires an appropriate supported AD and SSO deployment.	Direct integration with a supported Active Directory environment.
Active Directory over LDAP	Active Directory queried through LDAP	Active Directory as an LDAP Server	Associated with the configured AD domain and LDAP connection settings.	Primarily used for compatibility with earlier vCenter SSO designs.	Legacy LDAP-based Active Directory integration.
OpenLDAP	OpenLDAP 2.4 or newer	OpenLDAP	More than one OpenLDAP identity source can be configured, with each source associated with its domain.	Directory connectivity and supported configuration are required.	Authentication against OpenLDAP directories.
Local operating system users	Accounts local to the operating system hosting the SSO server	`localos`	Only one local operating system identity source can be added.	Available only in a basic SSO deployment; unavailable when multiple SSO instances are deployed.	Authentication using local SSO-host accounts.
Built-in vCenter SSO system users	Users and groups created in the built-in SSO domain	`vsphere.local`	Created during installation and initially selected as the default identity source.	Managed through the built-in SSO administration account.	SSO administration, recovery, and built-in system access.

Active Directory Using Integrated Windows Authentication

The Web Client option Active Directory (Integrated Windows Authentication) connects SSO to a supported Active Directory environment using integrated Windows authentication.

A single AD domain can be selected as the identity source. The selected domain can be the forest root domain or a domain that contains child domains. A forest root domain is the highest-level domain in an Active Directory forest. A child domain is located beneath another domain in the domain tree.

Choose this source type when the vCenter SSO host and deployment are designed to integrate directly with the organization’s supported Active Directory environment.

Active Directory as an LDAP Server

The Web Client option Active Directory as an LDAP Server accesses Active Directory through LDAP rather than Integrated Windows Authentication.

This option is mainly relevant to environments aligned with the vSphere 5.1-era SSO implementation or other designs that require LDAP-based compatibility. The source type should match the connection model planned for the directory. Selecting the wrong AD option can prevent users from authenticating even when the directory itself is available.

OpenLDAP Integration

vCenter Server 5.5 supports OpenLDAP 2.4 and later as an identity source. The Web Client identifies this option as OpenLDAP.

More than one OpenLDAP identity source can be configured. Each source must be associated with its intended domain so SSO can distinguish users when multiple repositories contain similar usernames.

Local Operating System Users

The localos identity source represents accounts local to the operating system hosting the vCenter SSO server. These accounts are not users from Active Directory or OpenLDAP.

localos is available only for a basic SSO deployment.
It cannot be used when multiple SSO instances are deployed.
Only one local operating system identity source can be added.

These restrictions make localos unsuitable for deployments that require multiple SSO instances. Check the deployment topology before selecting it.

The Built-In vsphere.local Domain

SSO installation creates the built-in identity domain named vsphere.local. This domain is both the built-in system-user identity source and the initial default identity source.

The initial administrative identity is administrator@vsphere.local. The built-in administrator is used to perform core SSO administration, including:

Adding external identity sources.
Choosing the default identity source.
Managing SSO password policies.
Managing account lockout policies.
Administering built-in users and groups in vsphere.local.

Retain access to administrator@vsphere.local while testing external directory authentication. An external directory account should not replace the built-in administrative path until the external source and its permissions have been validated.

Default Identity Source Behavior

The default identity source is the directory SSO consults when a user enters an unqualified username, such as administrator. Immediately after installation, the default is vsphere.local.

If the default remains vsphere.local, entering administrator causes SSO to interpret the name as a user in the built-in domain. It does not automatically search every configured directory for a matching account.

Changing the default source changes the meaning of unqualified usernames. After an administrator selects an external directory as the default, a name such as john is resolved through that source instead of automatically being treated as a vsphere.local user. Administrators should review the current default whenever login behavior changes or multiple domains are configured.

Login Name Formats for External Domains

A user can explicitly identify an external domain by using either of these formats:

DOMAIN\username
username@domain.example

For example, a user named john in the CORP domain might sign in as:

CORP\john
john@corp.example

Both forms direct SSO to the specified external domain instead of relying on default-source resolution. Do not include a password in the login name. The password is entered separately in the sign-in interface.

Entered username	How SSO resolves it	Example use case
Unqualified username	SSO looks in the current default identity source.	`john` when the external directory is the default source.
`DOMAIN\username`	The domain prefix explicitly identifies the target domain.	`CORP\john`.
`username@domain.example`	The suffix identifies the target domain in user-principal-name style.	`john@corp.example`.
`administrator@vsphere.local`	SSO resolves the built-in administrator in the built-in SSO domain.	Initial SSO administration and recovery access.

Adding and Reviewing an Identity Source

Open the vCenter SSO administration interface in the vCenter Web Client.
Add an identity source.
Select the appropriate source type: Active Directory (Integrated Windows Authentication), Active Directory as an LDAP Server, OpenLDAP, or localos where eligible.
Provide the required directory or account-repository settings.
Associate the source with its intended domain.
Set or review the default identity source.
Test authentication with a fully qualified username before relying on unqualified names.

Use administrator@vsphere.local to manage built-in SSO users, groups, password settings, lockout settings, identity sources, and default-source selection.

Planning and Selection Considerations

Requirement	Suitable source	Important limitation or note
Windows Active Directory integration	Active Directory (Integrated Windows Authentication)	Use for a supported direct AD integration and select the intended AD domain.
Legacy LDAP-based AD compatibility	Active Directory as an LDAP Server	Uses LDAP and primarily supports designs aligned with earlier SSO implementations.
OpenLDAP directory integration	OpenLDAP	OpenLDAP 2.4 or newer is required; multiple sources can be configured.
Local SSO-host accounts	`localos`	Only one source is allowed, and it is limited to a basic SSO deployment.
Built-in emergency and administrative access	`vsphere.local`	Keep `administrator@vsphere.local` available while external authentication is being validated.

Base the selection on the organization’s directory platform, domain design, SSO deployment topology, and compatibility requirements. Also distinguish the built-in SSO domain from the organization’s AD domain when documenting procedures and assigning permissions.

Troubleshooting Identity-Source Logins

An unqualified username cannot sign in

Check whether the expected directory is the current default identity source. If the user belongs to an external domain, retry with DOMAIN\username or username@domain.example. Confirm that the required identity source is configured and associated with the correct domain.

Local operating system accounts cannot be added

Verify that the deployment is a basic SSO deployment and that multiple SSO instances are not present. Also confirm whether the single allowed localos identity source has already been configured.

Active Directory users cannot authenticate

Verify whether the intended design requires Integrated Windows Authentication or LDAP-based AD access. Check the configured domain and test a fully qualified username. An incorrect source type, domain designation, or domain association can prevent authentication.

Built-in SSO administration is unavailable

Use administrator@vsphere.local to access built-in SSO administration. An external account may not yet have the required access, and an unqualified name may resolve through an unexpected default identity source.

Exam-Relevant Notes

An identity source supplies users and groups for authentication; vCenter roles and permissions provide authorization.
Every identity source is associated with a domain.
vsphere.local is created during installation and is initially the default identity source.
administrator@vsphere.local is the built-in SSO administrative identity.
Integrated Windows Authentication and LDAP-based Active Directory are separate source types.
OpenLDAP support begins with version 2.4, and more than one OpenLDAP source can be configured.
localos is limited to one source and a basic SSO deployment.
Use a domain-qualified login when the user belongs to a nondefault domain.

For related study material, see SSO Identity Sources.