VMware vCenter: Howto add an Active Directory Domain as SSO Identity Source and using system session credentials

Attention: If plan a update to VMware vSphere/vCenter 5.1.0 Update 1. Currently this version contains a bug which prevents User from Login. VMware is working on an Fix. See KB2050941

=> Bug is solved in 5.1.0 Update 1a

Hi everybody,

since VMware vCenter 5.1 a new service SSO, the Single Sign On Service,  handles the authentication for all logons. The advantage is that multiple authentication sources are possible. For example Local User and groups, OpenLDAP Directory Services and of course Microsofts Active Directory.

This post is related to vCenter Version 5.1.0b and describes how to add an Active Directory Domain as Identity source and get this running by using the “Reuse session” Authentication Type. The last one is the tricky part :-).

Let us start. Start the vSphere WebClient with a login which owns the appropriate rights, for example admin@system-domain or any other user who owsn has the SSO administrator privileges, and navigate to Administration/Sign On and Discovery/Configration. In the default configuration two identity sources are added by default. The SSO database and the user management of the local server.

To add an Active Directory as identity source the following informations are required

  • The Domain fully qualified domain name
  • The Domains NetBIOS Name
  • At least one domain controller
  • The Base DN for the users and groups

The attached powershell script GetSSOParameters.ps1 should determine this for your domain. You must start the script with the fully qualified domain name as parameter. Try it!

PS c:\>GetNetBiosDomainName.ps1 yourdomain.com
Basic Config for VMware SSO Identity source
Primary Server: ldap://domaincontroller1.yourdomain.com
Secondary Server: ldap://domaincontroller2.yourdomain.com
BaseDN Users: DC=yourdomain,DC=com
Domain: yourdomain.com
Domain Alias: YOURDOMAIN
BaseDN Groups: DC=yourdomain,DC=com

If you have the necessary information you can add the Identity source. See Screenshot below. First try to add by specifing a Username and a password which have the rights to query the Active Directory

VMware SSO Identity Source with "Password" option
VMware SSO Identity Source with “Password” option

Press the Test Connection Button and normally this return that the connection is successfully established.

Config successfully verified
Config successfully verified

But these way has a significant disadvantage. If you change your password, the SSO service could not connect to Active Directory anymore :-(. In large AD environments it is often not allow to  set the “Password never expires” property for a user. From security reasons the password must frequently changed. Therefore each time you change your password you have to alter the Identity Source Entry as well.

The better choice is to use the “Reuse session” Authentication Type option.

VMware SSO Identity Source with "Reuse Session"
VMware SSO Identity Source with “Reuse Session”

But I did not get this running within the Webclient GUI. A GSSAPI Error occured.


and in the SSO imsTrace Logfile ( VMware\Infrastructure\SSOServer\logs\imsTrace.log ) some errors has been written:

  • (LDAPConnectionTesterImpl.java:231), trace.com.rsa.ims.ldapslotmgt.impl.LDAPConnectionTesterImpl, ERROR, vCenter.yourdomain.com,,,,LDAP Server connection test failed
  • javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Message stream modified (41))]]
  • GSSException: No valid credentials provided (Mechanism level: Message stream modified (41))
  • KrbException: Message stream modified (41)

But if Kerberos is properly configured this should also work. The SSO Server is running with the Windows SYSTEM Account. If the service connects to the AD it uses the session from the computer object and therefore reading and processing a query must be possible , and authentication too. Unfortunatly the “reuse session” can’t be force without pressing the “Test connection” Button. Forcing from commandline isn’t also possible. So I tried a hack.

I added the identity source with the User/Password Option and then I tried to change the Authentication type directly in the SSO Database. Do connect to the database I installed the Microsoft SQL Server Management Studio for Express Editions and connect to the SSO Database (for me localhost\VIM_SQLEXP) with SQL Authentication and with the SSO Database Admin (Default User: RSA_DBA) which was specified at installation time. When you are connected, you have to determine your Identity Source Entry with the following SQL query.

FROM [RSA].[dbo].[IMS_CONFIG_VALUE] where NAME like 'ims.ldap-slots.%' order by NAME

this should return something like this:

NAME                                      VALUE
ims.ldap-slots.2.gssapi-supported          false
ims.ldap-slots.2.password                  UEQ5NGJXd2dkbVZ5YzJsdmJqMGlNUzR3.....
ims.ldap-slots.2.primary-url               ldap://domaincontroller1.yourdomain.com
ims.ldap-slots.2.secondary-url             ldap://domaincontroller2.yourdomain.com
ims.ldap-slots.2.username                  UEQ5NGJXd2dkbVZ5YzJsdmJqMGlNUzR3...
ims.ldap-slots.2-global.gssapi-supported   false
ims.ldap-slots.2-global.password           UEQ5NGJXd2dkbVZ5YzJsdmJqMGlNUzR3...
ims.ldap-slots.2-global.primary-url        ldap://domaincontroller1.yourdomain.com
ims.ldap-slots.2-global.secondary-url      ldap://domaincontroller2.yourdomain.com
ims.ldap-slots.2-global.username           UEQ5NGJXd2dkbVZ5YzJsdmJqMGlNUzR3....

now identify the Number of your Entry. In this case ims.ldap-slots.2.xxx => “2”.  Switch the authentication type directly in the config table of the database by this SQL UPDATE statement:

UPDATE [RSA].[dbo].[IMS_CONFIG_VALUE] SET VALUE='true' where NAME = 'ims.ldap-slots.2.gssapi-supported'
UPDATE [RSA].[dbo].[IMS_CONFIG_VALUE] SET VALUE='true' where NAME = 'ims.ldap-slots.2-global.gssapi-supported'
UPDATE [RSA].[dbo].[IMS_CONFIG_VALUE] SET VALUE=NULL where NAME = 'ims.ldap-slots.2.username'
UPDATE [RSA].[dbo].[IMS_CONFIG_VALUE] SET VALUE=NULL where NAME = 'ims.ldap-slots.2-global.username'

The SQL Update command returns how many rows affected:

(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

Restart the SSO Service by typing the following commands

net stop ssotomcat
net start ssotomcat

and try to login to vCenter with a user from the just added domain.  Use DOMAIN\USER as format for the username.

If this post this is useful for you or if you have a better approach please let me know these by adding a comment.

Have fun Michael

Advertisment to support michlstechblog.info

2.0 KiB

6 thoughts on “VMware vCenter: Howto add an Active Directory Domain as SSO Identity Source and using system session credentials”

  1. Very helpful, Thank you! I not yet installed web client and can’t edit Edit Identity Source, this solve my problem

  2. As single sign-on provides access to many resources once the user is initially authenticated (“keys to the castle”) it increases the negative impact in case the credentials are available to other persons and misused.

    1. Which credentials do you mean? There are no credentials available for other persons. The System credentials are only used to query the Active Directory.


Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.