- It is very similar to an Active Directory Domain Architecture
- It is an authentication broker
- It configures a vsphere.local domain (in vSphere 5.1 the local domain was called as “system-domain”)
The Single Sign-on (SSO) Architecture part of vCenter in vSphere 5.5 has following features:
- It uses a Kerberos type (token based) authentication mechanism
- It uses a Secure Token Protocol for Authentication
- You can create one-way trust relationships with existing Windows Active Directory Domains or OpenLDAP domains
- You can have multiple such trust relationships defined. Being able to define multiple trust relationships is very useful in a cloud enabled era.
One of the important things that you should remember is (and hopefully that would remove a lot a confusion) this vCenter Single Sign-on infrastructure is only used for authenticating users/groups to vSphere Infrastructure and applications that integrate with vCenter. It does not provide authentication services for desktops or other desktop/user applications. Or to say more correctly it is not a replacement for Active Directory Domain. In fact it works as a complementary solution to authenticate Active Directory users/groups to vSphere infrastructure.
In Single Sign-on infrastructure the default Single Sign-on administrator user is firstname.lastname@example.org. This user is an administrator on both the vsphere.local Single Sign-on domain and the vCenter Server inventory.
- On a Windows based vCenter Server System, you set the password for this user (email@example.com) during the installation of Single Sign-on.
- On a vCenter Server Appliance (Linux based virtual appliance) the firstname.lastname@example.org get created and defined during the initialization/configuration of the appliance.