SSO error: Unable to create a managed connection ‘ldaps://” with ‘GSSAPI’

While trying to add a vCenter Server to Log Insight, I encountered an error that just said “Incorrect username or password”. Well I tried again, no go. Tried my own admin account (that has god mode), still the same. I tried to logon to the particular vCenter with the vSphere Client and got the “Incorrect username and password” error again. Tried the Web Client and got the following error:

SSO2

“Malfunctioning identity source” – tells me there’s something up with one of the multiple AD domains I had in there. For a quick troubleshoot I tested connectivity to each identity source by editing each source and selecting “Test Connection”. Each identity source said “Connection established successfully” except for one. This particular source failed the probing for connectivity test once, thinking it may have been a fluke I tried it again and the second time it came back successful. This did ring a bell though, I had heard of latency issues for connectivity to this source’s Domain Controllers in the past. With this in mind, I tried logging in again to the Web Client so as to generate fresh entries in the imstrace.log file in the SSO VM. As expected, the logon event failed. Cracked open the imstrace.log file and came across the following entries:

com.rsa.common.UnexpectedDataStoreException: Failed group search, unexpected interrupt
Caused by: javax.naming.NamingException: getInitialContext failed. javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection ‘ldaps://<redacted>:3269’ with ‘GSSAPI’ Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <redacted>:3269 [Root exception is javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection ‘ldaps://<redacted>:3269’ with ‘GSSAPI’ Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <redacted>:3269]
Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create a managed connection ‘ldaps://<redacted>’ with ‘GSSAPI’ Reason: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <redacted>:3269
Caused by: javax.resource.spi.ResourceAdapterInternalException: Unable to create managed connection <redacted>:3269
Caused by: javax.naming.CommunicationException: <redacted>:3269 [Root exception is java.net.SocketException: Connection reset]
Caused by: java.net.SocketException: Connection reset

The log doesn’t give you the name of the offending identity source in plain human readable format, it gives you the GUID of the identity source instead. Not very human-friendly now, is it? The way to refer it back to actual name of the identity source is to crack open the SSO database. The credentials to the user account that can connect to and peer into SSO (called the RSA database) are contained in the config.properties file located in the following location > <install location>\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes. I was honestly surprised to see the credentials in plain text! But it is what it is. Anyways, connecting to the SQL database with SQL Authentication (using the credentials in plain text) reveals the RSA database. Next, based on the hint here, I looked at the various entries in the database tables and they showed up like this:

SSO4

Each identity source you have is going to occupy a slot. The slots start from zero and their number is equal to the number of identity sources you have. Now all you gotta do is match the GUID in the imstrace.log (where you see the above quoted error) to the GUID shown as above. That’s the offending identity source. You can either delete it if you no longer need it. Or you can delete and recreate. Know that deleting a source will prevent users from that domain from logging in. In this case, authentication was already broken.

Another thing to keep in mind, which in my opinion is a little odd, is all your identity sources need to be up and working otherwise SSO is going to throw you these SAML token errors. I find this odd because I’d think if you were trying to logon against say domain ABC, and domain XYZ was having connectivity problems, you should still be able to logon.

Do take a look at the various database tables in the RSA database. A wealth of information of the internals of SSO is revealed. Dont tinker with it though, any changes you make to the tables are effective right away!

2 Comments

 Add your comment
  1. Spent hours looking for a solution to my SSO issues. Thanks, this saved my skin!

Leave a Comment

Your email address will not be published.