VMware vSphere 5.1 – Some tips around Single Sign On

When I did my first installations or upgrades to vSphere 5.1 I struggled with the new single sign on server. Here I will provide you some tips to prevent some pitfalls.


SSO database (connection)

SSO requires its own database but this is not the problem. Before your start the SSO installation you should have already prepared the database and the SQL user(s).

In the first step you need to run a SQL script which will create a new database called “RSA” and insert the required table spaces. This script can be found in:

VMware-VIMSetup-all-5.1.0-880471\Single Sign On\DBScripts\SSOServer\schema\mssql\ rsaIMSLiteMSSQLSetupTablespaces.sql

You can do so by using the  SQL Server Management Studio, just open the file and execute it.

Later on the installer will ask you for two users to access the database. The funny thing is, this only works with SQL users! No support for Windows authentication.

VMware recommends creating the following two users: RSA_DBA + RSA_User

This can be also done manually or via another predefined script:

VMware-VIMSetup-all-5.1.0-880471\Single Sign On\DBScripts\SSOServer\schema\mssql\ rsaIMSLiteDBNameSetupUsers.sql

If you run the scripts in the order I mentioned above you should be fine. If you create the users manually, make sure the RSA_DBA gets the sysadmin rights.

Quote out of the SetupUsers script:

“The DBA account is used during installation and the USER account is used during operation” 

The RSA_USER needs rights to access the “RSA” SSO database. I guess the most of you know this procedure from creating a vCenter or an Update Manager database.


SSO configuration

When you login to the web client you can add single users or groups to you single sign on server. But you should know these will only exist within the SSO “System-Domain”. SSO won’t create local Windows/AD users for you.

Users you add/create here will only have permissions to login into the web client and view or edit SSO settings. But what you really need is an identity source, which can be added (if not  happened automatically):

This identity source will be queried every time you login to your vSphere or web client. The reason why I highlighted the “CN=Users” part in the Base DN for groups line, is that at the moment queries can time out if your active directory contains many groups/OUs. This is a workaround to limit SSO to search for objects only within a particular group or OU.

And don’t forget to set the alias. Otherwise you will run into problems when you want to use your windows session credentials. Your session will send ALIAS\Username but if you don’t set a domain alias your SSO will wait for home.local\Username. At least we had some issues without the proper alias; feel free to provide some feedback if I’m wrong here.

When you don’t use your current Windows session you will need to provide the domain that SSO is able to query the right identity source. The same can be necessary if you use local user accounts <computername>\<local user>

I hope this will help you to a bit then you set up your single sign on server. And don’t forget to check the vSphere Installation and Setup Guide.


*UPDATE* (21.05.2013)

Today I stumbled upon a problem where the login in general worked fine but some specific users I got the following error message:

Web client:

“The authentication server returned an unexpected error: ns0:RequestFailed: Internal Error while creating SAML 2.0 Token. The error may be caused by a malfunctioning identity source.”

vSphere client:


I checked the imsTrace.log located in <vCenter Installation path>\SSOServer\logs, where I   received the following error every time I attempted to login:

“… Failed group search, unexpected interrupt …”

This information led me straight to KB2050941

All I had to do, was to remove the second domain / identity source within the SSO server, which wasn’t needed at all (luckily) but that fixed it!

*UPDATE* (23.05.2013)

vCenter Server 5.1 Update 1 has been released


Print Friendly, PDF & Email

Related Post