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
NAME: YOURDOMAIN
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
Press the Test Connection Button and normally this return that the connection is successfully established.
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.
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.
SELECT [NAME] ,[VALUE] 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
Hello,
great article and usefull powershell script.
In your script, may be you can change the LDAP URL to use the AD Global Catalog’s port (by adding ‘:3268’ at the ldap URL’s end ) instead of the LDAP 389, as recommended in the vmware documentation: http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-33ED845B-6310-4B4E-A704-8DAD26074320.html
Hi jean-bernard, thanks for the tip. I will change the script during the next week.
Very helpful, Thank you!
Very helpful, Thank you! I not yet installed web client and can’t edit Edit Identity Source, this solve my problem
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.
Which credentials do you mean? There are no credentials available for other persons. The System credentials are only used to query the Active Directory.
Michael