vCenter 5.1 SSO SAML 2.0 Token Error


While testing a vCenter 5.0->5.1 upgrade we encountered the following error when logging on with any non-SSO account.

“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.”

After checking the SSO log files I was experiencing “The RPC server is unavailable” error as explained in this KB article. Apparently you must have short name resolution working – even if your DNS is properly configured for FQDN resolution.

Anyone working in a multi-domain/dns suffix environment can tell you that relying on short name resolution instead of full name resolution is a poor design decision. To resolve our issue, we had to end up relying on WINS. That’s right – registering the server in WINS allows the SSO application to resolve the necessary servers and create the SAML tokens correctly. Excuse me while I go file a bug report with VMware…

Share !

Recommend it to your friends & peers.

Share on Twitter StumbleUpon Reddit Digg del.icio.us Facebook LinkedIn Technorati
Posted by Brandon Hahn on October 23, 2012

6 Comments for this entry

October 26, 2012, 13:22

Hi Brandon
Thanks for the post I actually ran into the exact same problem.

without having to enable WINS i did the following.
Verified i had radio button selected for “Enable netbios over TCP/IP” on network config.
What actually caught me out was that my DNS suffix for the primary domain was not listed and after adding it i was able to work around this problem.
As a last resort I guess adding the DC names to the host file might also fix this.

I do however agree completely with you that this is not the best method and computer name only restriction might be more related to this particular command used within Microsoft. Still an implementation that VMware should be able to work around and resolve this hopefully.


October 26, 2012, 13:26

Johann – that certainly is another solution (and one I would have preferred over WINS) but was not something I could do easily in my environment. It seems like the key is the DNS server must be able to resolve the SSO server using the short name.

Brian E
January 2, 2013, 12:04

I stumbled across a new cause for the same error. It turned out that the user’s account in AD had a trailing space. For some reason this causes AD to report the container name with a backslash character, i.e. – CN=John Doe/ ,ou=etc. Once we removed the space in AD, the user was able to logon.

Neil T
May 14, 2013, 15:06

Adding parent/child DNS suffixes to the vCenter server fixed this for me as well.


Dennis Bray
June 28, 2013, 14:42

I was also able to remedy the error by adding the DNS suffixes for each AD domain in use.

Ghent Gunn
April 30, 2014, 19:17

I ran into this issue as well, but my root cause was different.
I upgrade from vCloud 5.1.2 to 5.1.3.
After upgrading VSM, vCloud, SSO, and the vSphere Web Client, I got this error when trying to log in as a domain user to the SSO.
My issue is that I had was:
– I had multiple Identity Sources
– and one of them was configured to use ldaps (which uses SSL) on port 3269
– and it had an expired certificate.
Even though the Identity source with the expired certificate was NOT the domain I was trying to log into, removing it caused the error to go away and allow me to successfully log into the other domains.

The main error in my imsTrace log I was:
Caused by: javax.naming.CommunicationException: simple bind failed: MyADServer.My.Company.Domain.com:3269 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed]

Again, even though it was not on the domain I was trying to use, removing it made the issue go away — of course, I can’t log into the domain I removed — but in this case I’m OK with that until I can update the certificate.

Leave a Reply

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