VMware ESXi and vSphere Cluster Management

vCenter Single Sign-On Identity Sources

Learn how vCenter Server 5.5 SSO identity sources work, including Active Directory, LDAP, OpenLDAP, localos, vsphere.local, and default-domain login rules.

What an identity source does

An identity source is a configured repository of users and groups that vCenter Single Sign-On (SSO) consults when validating a login. Directory services are the typical repositories, but vCenter Server 5.5 can also use local operating-system accounts and its built-in SSO domain.

Each configured identity source is associated with a domain. The domain is the identity namespace used to distinguish accounts and qualify usernames. Because multiple sources can be associated with different domains, SSO can authenticate users from more than one directory environment.

Supported vCenter Server 5.5 identity sources

In the vSphere Web Client, the supported source types have distinct names. The connection method and SSO deployment topology matter when selecting one.

Identity source type: Active Directory using Integrated Windows Authentication
Web Client name: Active Directory (Integrated Windows Authentication)
Supported directory version: Active Directory 2003 and later
Quantity or scope: One Active Directory domain
Deployment restrictions: The selected domain can be a forest-root domain or a domain containing child domains
Primary use: Standard Windows-integrated authentication to Active Directory

Identity source type: Active Directory as an LDAP server
Web Client name: Active Directory as an LDAP Server
Supported directory version: Active Directory accessed through LDAP
Quantity or scope: Configured as an Active Directory LDAP source
Deployment restrictions: Separate from the integrated-authentication option
Primary use: Compatibility with the earlier vSphere 5.1 SSO approach

Identity source type: OpenLDAP
Web Client name: OpenLDAP
Supported directory version: OpenLDAP 2.4 and later
Quantity or scope: More than one OpenLDAP source may be registered
Deployment restrictions: The directory must meet the supported OpenLDAP version requirement
Primary use: Authentication against one or more OpenLDAP directories

Identity source type: Local operating-system users
Web Client name: localos
Supported directory version: Not applicable; accounts are on the SSO server operating system
Quantity or scope: One local operating-system identity source
Deployment restrictions: Available only in a basic SSO deployment; unavailable when multiple SSO instances are present
Primary use: Authentication with accounts local to the operating system hosting vCenter SSO

Identity source type: vCenter SSO system users
Web Client name: vsphere.local
Supported directory version: Not applicable; created by SSO installation
Quantity or scope: One built-in SSO domain
Deployment restrictions: Created during installation and managed by SSO
Primary use: SSO-managed users and groups, including the initial administrator

Active Directory with Integrated Windows Authentication

Active Directory (Integrated Windows Authentication) supports Active Directory 2003 and later. In vCenter Server 5.5, one Active Directory domain can be configured as this type of identity source.

The selected domain may be the forest-root domain, or it may be a domain that contains child domains. This option uses Windows-integrated authentication rather than a direct LDAP-style configuration. It is the usual choice when the environment is designed around the standard Active Directory integration method.

Active Directory as an LDAP server

Active Directory as an LDAP Server connects to Active Directory through LDAP. It is a different identity-source type from Active Directory integrated authentication.

This option has a historical compatibility role for environments that used the earlier vSphere 5.1 SSO approach. Choose it when compatibility with that model is the deciding requirement; otherwise, evaluate the integrated Active Directory option as the standard AD method.

OpenLDAP

OpenLDAP identity sources support OpenLDAP 2.4 and later. Unlike the single integrated Active Directory domain limit, more than one OpenLDAP source may be registered.

Each OpenLDAP source should have its own associated domain so that SSO can distinguish users with the same username in separate directories.

Local operating-system users: localos

The localos source represents accounts stored on 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 is unavailable when the deployment contains multiple SSO instances. Only one local operating-system identity source can be configured.

Consequently, localos is a topology-dependent choice rather than a general replacement for an external directory. Confirm the SSO deployment model before planning to use it. For related topology concepts, see Deployment Modes in vCenter SSO.

The built-in vsphere.local domain

The vsphere.local domain is created during SSO installation. It is the built-in identity source for users and groups managed directly by vCenter SSO.

The initial administrative account in this domain is administrator, normally written as administrator@vsphere.local. This account can administer identity sources, select the default identity source, manage password and account-lockout settings, and administer users and groups in the SSO domain.

The internal domain is distinct from externally managed domains. Adding an Active Directory or OpenLDAP source does not replace the vsphere.local source or move the built-in administrator account into the external directory.

Default identity source and username interpretation

After installation, vsphere.local is initially the default identity source. The default source is used when a user signs in with an unqualified username, meaning the username does not include a domain.

For example, entering administrator without a domain causes SSO to evaluate that name in the current default domain. To explicitly select the internal SSO domain, use administrator@vsphere.local.

Users from external domains should provide the domain explicitly. vCenter SSO 5.5 accepts these qualified-login forms:

  • DOMAIN\username, such as CORP\john
  • username@domain.example, such as john@corp.example

Login form: Unqualified username
Example: john
When it is used: The user expects the account to be in the default identity source
How SSO resolves it: SSO evaluates the name in the configured default domain

Login form: DOMAIN\username
Example: CORP\john
When it is used: A Windows-style domain-qualified login is required
How SSO resolves it: SSO uses the specified domain instead of relying on the default source

Login form: username@domain.example
Example: john@corp.example
When it is used: A user signs in with a UPN-style qualified name
How SSO resolves it: SSO uses the domain portion to select the matching identity source

Login form: administrator@vsphere.local
Example: administrator@vsphere.local
When it is used: Initial or explicit administration of the internal SSO domain
How SSO resolves it: SSO selects the built-in vsphere.local source

Choosing the correct default source affects administrator and user login behavior. A default source makes short usernames convenient, but a user whose account exists in another domain must either qualify the username or change the default source. During initial administration, explicitly use administrator@vsphere.local so that the internal account is not confused with an external account named administrator.

How to select and configure an identity source

  1. Open the vSphere Web Client and go to the SSO administration area.
  2. Add the required external directory source, selecting the appropriate source type.
  3. Review the domain associated with the source. The domain is used for qualified usernames and must identify the intended directory namespace.
  4. Set the desired default identity source.
  5. Test both an unqualified login, if you intend to use one, and a domain-qualified login.
  6. Retain administrator@vsphere.local for explicit internal-domain SSO administration.

For the standard Active Directory approach, evaluate Active Directory (Integrated Windows Authentication). Use Active Directory as an LDAP Server when compatibility with the earlier SSO model is important. Use OpenLDAP for OpenLDAP 2.4 or later, and consider localos only when the basic-deployment and single-source restrictions are satisfied.

Identity-source limits and constraints

Source: Single integrated Active Directory domain
Constraint: Only one Active Directory domain can be configured with Integrated Windows Authentication
Administrative impact: Choose the domain carefully; it may be the forest root or a domain containing child domains

Source: Multiple OpenLDAP sources
Constraint: More than one OpenLDAP source may be registered
Administrative impact: Associate each source with a distinguishable domain and qualify usernames when needed

Source: One localos source
Constraint: Only one local operating-system identity source can be configured
Administrative impact: Do not plan for multiple localos repositories

Source: localos with multiple SSO instances
Constraint: localos is unavailable in a deployment containing multiple SSO instances
Administrative impact: Confirm topology before selecting local operating-system authentication

Source: vsphere.local
Constraint: Created during SSO installation as the built-in SSO domain
Administrative impact: Keep the internal administrator account available for SSO administration

Choosing between identity sources

Compare candidates using five questions:

  • Directory type: Is the repository Active Directory, OpenLDAP, or the local operating system?
  • Authentication mechanism: Should Active Directory use Integrated Windows Authentication or LDAP?
  • Supported version: Is the directory at least Active Directory 2003 or OpenLDAP 2.4, where applicable?
  • Source quantity: Does the design require one integrated AD domain, multiple OpenLDAP sources, or one localos source?
  • SSO topology: Is the deployment basic, or does it contain multiple SSO instances?

Keep the internal vsphere.local domain separate from externally managed directory domains. External sources provide directory identities, while the internal source provides SSO-managed identities and administration.

Practical login examples

Built-in SSO administrator

For initial SSO administration, sign in as administrator@vsphere.local. This explicitly selects the internal domain and avoids dependence on whichever source is currently default.

Active Directory user

Suppose the user is named john in the CORP domain. Use CORP\john or john@corp.example rather than relying on the default source.

Separate directory environments

An organization can configure an Active Directory source for corporate staff and one or more OpenLDAP sources for teams maintained in separate LDAP directories. Users should qualify their names when the relevant directory is not the default.

Local account source

Use localos only when SSO runs in a basic deployment and local operating-system accounts are specifically required. It cannot be added to a deployment with multiple SSO instances.

Troubleshooting identity-source logins

An unqualified username cannot authenticate

The account may not exist in the current default identity source. Enter a qualified username, such as CORP\john or john@corp.example, or verify the configured default source.

The administrator cannot access SSO management

The internal account may have been entered without its domain. Sign in explicitly with administrator@vsphere.local.

The localos source cannot be added

Check whether the SSO topology contains multiple SSO instances. Also verify that a localos source does not already exist. localos requires a basic deployment and only one such source is allowed.

OpenLDAP does not meet the requirement

Verify the directory version. vCenter Server 5.5 requires OpenLDAP 2.4 or later for this identity-source type.

The Active Directory option does not match the environment

Integrated Windows Authentication and Active Directory over LDAP are separate source types. Select the integrated option for the standard AD method, or select the LDAP option when compatibility with the earlier SSO model is required.

Exam-relevant summary

  • An identity source is a user and group repository used by SSO during authentication.
  • Every identity source is associated with a domain.
  • Active Directory (Integrated Windows Authentication) supports Active Directory 2003 and later and permits one AD domain.
  • Active Directory as an LDAP Server uses LDAP and supports compatibility with the earlier vSphere 5.1 SSO approach.
  • OpenLDAP supports version 2.4 and later, and more than one OpenLDAP source can be registered.
  • localos represents accounts on the vCenter SSO server operating system, is limited to a basic deployment, is unavailable with multiple SSO instances, and can be configured only once.
  • vsphere.local is created during installation and contains the initial administrator account.
  • vsphere.local is initially the default identity source.
  • Unqualified names use the default domain; qualified names use DOMAIN\username or username@domain.example.
  • Authentication through an identity source does not grant vSphere permissions by itself.

For broader vSphere administration context, see the VMware ESXi Online Course, and for SSO policy administration see Configure vCenter SSO Policies.