Add or Edit a vCenter Single Sign-On Identity Source

Users can log in to vCenter Server only if they are in a domain that has been added as a vCenter Single Sign-On identity source. vCenter Single Sign-On administrator users can add identity sources, or change the settings for identity sources that they added.

An identity source can be an Active Directory over LDAP, a native Active Directory (Integrated Windows Authentication) domain, or an OpenLDAP directory service. See Identity Sources for vCenter Server with vCenter Single Sign-On.

Immediately after installation, the vsphere.local domain (or the domain you specified during installation) with the vCenter Single Sign-On internal users is available.

Note:

If you have updated or replaced your Active Directory SSL certificate, you must remove and re-add the identity source in vCenter Server.

Prerequisites

If you are adding an Active Directory (Integrated Windows Authentication) identity source, the vCenter Server must be in the Active Directory domain. See Add a vCenter Server to an Active Directory Domain.

Procedure

Log in with the vSphere Client to the vCenter Server.
Specify the user name and password for administrator@vsphere.local or another member of the vCenter Single Sign-On Administrators group.
If you specified a different domain during installation, log in as administrator@ mydomain.
Navigate to the Configuration UI.
1. From the Home menu, select Administration.
2. Under Single Sign On, click Configuration.
Under the Identity Provider tab, click Identity Sources, and click Add.

Select the identity source and enter the identity source settings.

Option	Description
Active Directory (Integrated Windows Authentication)	Use this option for native Active Directory implementations. The machine on which the vCenter Single Sign-On service is running must be in an Active Directory domain if you want to use this option. See Active Directory Identity Source Settings.
Active Directory over LDAP	This option requires that you specify the domain controller and other information. See Active Directory over LDAP and OpenLDAP Server Identity Source Settings.
OpenLDAP	Use this option for an OpenLDAP identity source. See Active Directory over LDAP and OpenLDAP Server Identity Source Settings.

Note:

If the user account is locked or deactivated, authentications and group and user searches in the Active Directory domain fail. The user account must have read-only access over the User and Group OU, and must be able to read user and group attributes. Active Directory provides this access by default. Use a special service user for improved security.

Click Add.

What to do next

Initially, each user is assigned the No Access role. A vCenter Server administrator must assign the user at least to the Read Only role before the user can log in. See the topic on using roles to assign privileges in the vSphere Security documentation.

Active Directory over LDAP and OpenLDAP Server Identity Source Settings

The Active Directory over LDAP identity source is preferred over the Active Directory (Integrated Windows Authentication) option. The OpenLDAP Server identity source is available for environments that use OpenLDAP.

If you are configuring an OpenLDAP identity source, see the VMware knowledge base article at https://kb.vmware.com/s/article/2064977 for additional requirements.

Important: Groups in AD-over-LDAP identity sources cannot use users in different domains even if you create an additional identity source for each domain.

Groups in LDAP identity sources only recognize those users that exist in the specified user base DN. This can lead to unexpected problems in large Active Directory environments with child domains. For example, consider the following scenario:

An Active Directory forest with two child domains, ChildA and ChildB.
A vCenter Server configured with two AD-over-LDAP identity sources, one for child domain ChildA and one for child domain ChildB.
ChildA contains two users named UserA1 and UserA2.
ChildB contains two users named UserB1 and UserB2.

The vCenter Server administrator creates a group in ChildA named TestGroup that contains UserA1, UserA2, UserB1, and UserB2. The vCenter Server administrator grants login (or any) privileges to TestGroup. Unfortunately, UserB1 and UserB2 cannot log in because they reside in a different domain than the group.

As a workaround, perform the following:

Create another group named SecondTestGroup in ChildB.
Remove UserB1 and UserB2 from TestGroup.
Add UserB1 and UserB2 to SecondTestGroup.
In vCenter Server, assign SecondTestGroup the same privileges that were granted to TestGroup.

Note: Microsoft Windows changed the default behavior of Active Directory to require strong authentication and encryption. This change impacts how vCenter Server authenticates to Active Directory. If you use Active Directory as your identity source for vCenter Server, you must enable LDAPS. For more information about this Microsoft security update, see https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023 and https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html.

Table 1. Active Directory over LDAP and OpenLDAP Server Settings
Option	Description
Name	Name of the identity source.
Base DN for users	Base Distinguished Name for users. Enter the DN from which to start user searches. For example, cn=Users,dc=myCorp,dc=com.
Base DN for groups	The Base Distinguished Name for groups. Enter the DN from which to start group searches. For example, cn=Groups,dc=myCorp,dc=com.
Domain name	The FQDN of the domain.
Domain alias	For Active Directory identity sources, the domain's NetBIOS name. Add the NetBIOS name of the Active Directory domain as an alias of the identity source if you are using SSPI authentications. For OpenLDAP identity sources, the domain name in capital letters is added if you do not specify an alias.
User name	ID of a user in the domain who has a minimum of read-only access to Base DN for users and groups. The ID can be in any of these formats: UPN (user@domain.com) NetBIOS (DOMAIN\user) DN (cn=user,cn=Users,dc=domain,dc=com) The user name must be fully-qualified. An entry of "user" does not work.
Password	Password of the user who is specified by Username.
Connect to	Domain controller to connect to. Can be any domain controller in the domain, or specific controllers.
Primary Server URL	Primary domain controller LDAP server for the domain. You can use either the host name or the IP address. Use the format `ldap://hostname_or_IPaddress:port` or `ldaps://hostname_or_IPaddress:port`. The port is typically 389 for LDAP connections and 636 for LDAPS connections. For Active Directory multi-domain controller deployments, the port is typically 3268 for LDAP and 3269 for LDAPS. A certificate that establishes trust for the LDAPS endpoint of the Active Directory server is required when you use `ldaps://` in the primary or the secondary LDAP URL.
Secondary server URL	Address of a secondary domain controller LDAP server that is used when the primary domain controller is unavailable. You can use either the host name or the IP address. For every LDAP operation, vCenter Server always tries the primary domain controller before falling back to the secondary domain controller. This can lead to Active Directory logins taking some time, and even failing, when the primary domain controller is unavailable. Note: When the primary domain controller fails, the secondary domain controller might not take over automatically.
Certificates (for LDAPS)	If you want to use LDAPS with your Active Directory LDAP Server or OpenLDAP Server identity source, click `Browse` to select a certificate that was exported from the domain controller specified in the LDAPS URL. (Note that the certificate used here is not a root CA certificate.) To export the certificate from Active Directory, consult the Microsoft documentation. You can browse for and select multiple certificates. Tip: When browsing for and selecting multiple certificates, they must be located in the same directory. vCenter Server only trusts certificates directly signed by a registered and trusted certificate authority. vCenter Server does not trace a path up to a registered CA certificate and only checks if the certificate is signed by a registered and trusted certificate authority. As long as your certificate is signed by a publicly trusted certificate authority, or is self-signed, no further action is necessary. However, if you create your own internal certificates (that is, you use a private certificate authority), you might need to include those certificates. For example, if your organization uses Microsoft Enterprise Root Certificate Authority to generate the LDAPS certificate, you must also select the Enterprise Root Certificate to add it to vCenter Server. In addition, if you use intermediate certificate authorities between the LDAPS certificate and the Enterprise Root certificate, you must also select those intermediate certificates to add them to vCenter Server.

Active Directory Identity Source Settings

If you select the Active Directory (Integrated Windows Authentication) identity source type, you can use the local machine account as your SPN (Service Principal Name) or specify an SPN explicitly. You can use this option only if the vCenter Single Sign-On server is joined to an Active Directory domain.

Prerequisites for Using an Active Directory (Integrated Windows Authentication) Identity Source

You can set up vCenter Single Sign-On to use an Active Directory (Integrated Windows Authentication) identity source only if that identity source is available. Follow the instructions in the vCenter Server Configuration documentation.

Note: Active Directory (Integrated Windows Authentication) always uses the root of the Active Directory domain forest. To configure your Integrated Windows Authentication identity source with a child domain within your Active Directory forest, see the VMware knowledge base article at https://kb.vmware.com/s/article/2070433.

Select Use machine account to speed up configuration. If you expect to rename the local machine on which vCenter Single Sign-On runs, specifying an SPN explicitly is preferable.

If you have enabled diagnostic event logging in your Active Directory to identify where hardening might be needed, you might see a log event with Event ID 2889 on that directory server. Event ID 2889 is generated as an anomaly rather than a security risk when using Integrated Windows Authentication. For more information about Event ID 2889, see the VMware knowledge base article at https://kb.vmware.com/s/article/78644.

Table 2. Add Identity Source Settings
Text Box	Description
Domain name	FQDN of the domain name, for example, mydomain.com. Do not provide an IP address. This domain name must be DNS-resolvable by the vCenter Server system.
Use machine account	Select this option to use the local machine account as the SPN. When you select this option, you specify only the domain name. Do not select this option if you expect to rename this machine.
Use Service Principal Name (SPN)	Select this option if you expect to rename the local machine. You must specify an SPN, a user who can authenticate with the identity source, and a password for the user.
Service Principal Name (SPN)	SPN that helps Kerberos to identify the Active Directory service. Include the domain in the name, for example, STS/example.com. The SPN must be unique across the domain. Running the setspn -S command checks that no duplicate is created. See the Microsoft documentation for information on setspn.
User Principal Name (UPN) Password	Name and password of a user who can authenticate with this identity source. Use the email address format, for example, jchin@mydomain.com. You can verify the User Principal Name with the Active Directory Service Interfaces Editor (ADSI Edit).

Add or Remove an Identity Source Using the CLI

You can use the sso-config utility to add or remove an identity source.

An identity source can be a native Active Directory (Integrated Windows Authentication) domain, AD over LDAP, AD over LDAP using LDAPS (LDAP over SSL), or OpenLDAP. See Identity Sources for vCenter Server with vCenter Single Sign-On. You also use the sso-config utility to set up smart card and RSA SecurID authentication.

Prerequisites

If you are adding an Active Directory identity source, the vCenter Server must be in the Active Directory domain. See Add a vCenter Server to an Active Directory Domain.

Enable SSH login. See Manage vCenter Server Using the vCenter Server Shell.

Procedure

Use SSH or another remote console connection to start a session on the vCenter Server system.
Log in as root.
Change to the directory where the sso-config utility is located.
```
cd /opt/vmware/bin
```
Refer to the sso-config help by running sso-config.sh -help, or see the VMware knowledge base article at https://kb.vmware.com/s/article/67304 for usage examples.