Oct12

vCenter 5.1 SSO SAML 2.0 Token Error

upgrade

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

5 Comments for this entry

Johann
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.

Cheers!

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.

Thanks.

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.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>