Identity sources allow you to attach one or more domains to vCenter Single Sign-On. A domain is a repository for users and groups that the vCenter Single Sign-On server can use for user authentication.
An identity source is a collection of user and group data. The user and group data is stored in Active Directory, OpenLDAP, or locally to the operating system of the machine where vCenter Single Sign-On is installed. Upon installation, every instance of vCenter Single Sign-On has the Local OS identity source identity source vsphere.local. This identity source is internal to vCenter Single Sign-On.
A vCenter Single Sign-On administrator user can create vCenter Single Sign-On users and groups.
Types of Identity Sources
vCenter Server versions earlier than version 5.1 supported Active Directory and local operating system users as user repositories. As a result, local operating system users could always authenticate to the vCenter Server system. vCenter Server version 5.1 and version 5.5 uses vCenter Single Sign-On for authentication. See the vSphere 5.1 documentation for a list of supported identity sources with vCenter Single Sign-On 5.1. vCenter Single Sign-On 5.5 supports the following types of user repositories as identity sources, but supports only one default identity source.
Active Directory versions 2003 and later. vCenter Single Sign-On allows you to specify a single Active Directory domain as an identity source. The domain can have child domains or be a forest root domain. Shown as Active Directory (Integrated Windows Authentication) in the vSphere Web Client.
Active Directory over LDAP. vCenter Single Sign-On supports multiple Active Directory over LDAP identity sources. This identity source type is included for compatibility with the vCenter Single Sign-On service included with vSphere 5.1. Shown as Active Directory as an LDAP Server in the vSphere Web Client.
OpenLDAP versions 2.4 and later. vCenter Single Sign-On supports multiple OpenLDAP identity sources. Shown as OpenLDAP in the vSphere Web Client.
Local operating system users. Local operating system users are local to the operating system where the vCenter Single Sign-On server is running. The local operating system identity source exists only in Simple vCenter Server installation and in Custom installations with a standalone vCenter Single Sign-On deployment. The local operating system identity source is not available in deployments with multiple vCenter Single Sign-On instances. Only one local operating system identity source is allowed. Shown as localos in the vSphere Web Client.
vCenter Single Sign-On system users. Exactly one system identity source named vsphere.local is created when you install vCenter Single Sign-On. Shown as vsphere.local in the vSphere Web Client.
At any time, only one default domain exists. If a user from a non-default domain logs in, that user must add the domain name (DOMAIN\user) to authenticate successfully.
vCenter Single Sign-On identity sources are managed by vCenter Single Sign-On administrator users.
You can add identity sources to a vCenter Single Sign-On server instance. Remote identity sources are limited to Active Directory and OpenLDAP server implementations.
When a user logs in to a vCenter Server system from the vSphere Web Client, the login behavior depends on whether the user is in the default domain.
Users who are in the default domain can log in with their user name and password.
Users who are in a domain that has been added to vCenter Single Sign-On as an identity source but is not the default domain can log in to vCenter Server but must specify the domain in one of the following ways.
Including a domain name prefix, for example, MYDOMAIN\user1
Including the domain, for example, email@example.com
Users who are in a domain that is not a vCenter Single Sign-On identity source cannot log in to vCenter Server. If the domain that you add to vCenter Single Sign-On is part of a domain hierarchy, Active Directory determines whether users of other domains in the hierarchy are authenticated or not.
vCenter Single Sign-On does not propagate permissions that result from nested groups from dissimilar identity sources. For example, if you add the Domain Administrators group to the Local Administrators group, the permissions are not propagated because Local OS and Active Directory are separate identity sources.