SSO can't survive a simple reboot... correction can't survive a password change!?

[vmrulz]

I've built up a development 5.1 environment with a few hosts and vcenter running on a Windows 2008r2 vm (on a different cluster). I'm running all services including SQL express on the VM. After many fits and starts I've had a decently running vcenter service. Today I needed to reboot vcenter because it was dog slow (Thank you JAVA!!!) and add some more memory.

Now I'm unable to authenticate via the web client or the fat client. I've restarted the SSO service ("thanks" for naming that service starting with vcenter unlike ALL the other services vmware) per kb 2033137.

Fat client error is: "a general system error occured: Authorize Exception

web client error is: The authentication server returned an unexpected error: ns0:RequestFailed: Failed to connect to the identity source. Possible reasons include invalid user name or password, connection refusal, connection timeout, or failure to resolve hostname. The error may be caused by a malfunctioning identity source.

Judging by the plethora of threads about SSO on the forums I'm going to step out on a limb and say this service "aint ready for primetime" and I'm sure glad I don't have a production environment on 5.1 yet!

[a_p_]

Afaik, the Windows Client doesn't use SSO at all, so this may be a different issue. Please take a look at http://kb.vmware.com/kb/1015639 to see whether removing/re-adding the vCenter Server from/to the domain solves the issue. Ensure you follow the steps in the KB article in order to preserve vCenter permissions!

André

[vmrulz]

Thanks for the reply. This to me is not even close to an acceptable solution to expect customers to do this on regular basis.

I did confirm that I can logon locally with both clients, I guess I'll jump through the remaining hoops and see.  VMware this better be part of an upcoming bug fix!

[a_p_]

Please don't get me wrong, I'm neither trying to defend VMware nor do any finger pointing, but if this issue is really caused by a lost domain connection, then this might rather be an issue with Windows itself than the vCenter Server Service or SSO running on this server.

André

[vmrulz]

Sorry that wasn't directed at you. I just don't like the "solution". I'm able to logon to the vcenter server with domain credentials yet not logon to any vcenter services with such creds. The domain and computer account in the domain are clearly not "lost".

[a_p_]

Don't worry, I didn't take this personally I'm just interested in what's causing the issue and the resolution, which I hope we will find.

In the years I've been woring with Windows systems, I saw issues with lost domain accounts a couple of times. Although users were able to logon (I assume du to a cached profile) there were issues with drive mapping, logon scripts, ... However, let's see what's going to happen after re-joining the server to the domain.

André

[vmrulz]

I had one of our guys who's never logged on to the vcenter box, logon with his domain creds just fine. I'll go through the domain hoops after I reboot it one more time.

post reboot I see event id 1000's for each group that has permissions in vcenter in the app log (while logged on to the vcenter server with a domain account):

"

The description for Event ID 1000 from source VMware VirtualCenter Server cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

The group account "DOMAIN\Group" could not be successfully resolved.  Check network connectivity to domain controllers and domain membership.  Users may not be able to log in until connectivity is restored.

the message resource is present but the message is not found in the string/message table "

When I logon to vcenter as local admin and attempt to add a permission to vcenter I get:

Call "UserDirectory.RetrieveUserGroups" for object "UserDirectory" on vCenter Server "servername" failed.

This could be trying to do an AD lookup with local admin I guess.

OK I guess I'm going to have to do the domain thing now.. seems silly.

[vmrulz · Accepted solution]

I need the lightbulb emoticon! So after almost 20 years in IT I should know that when things break after changing a password I should be suspicious of where those creds might be hidden.

So if I logon to the web client as the SSO admin admin@System-Domain and go to Administration > SSO > Configuration and click edit the AD Identity source, my elevated domain account which I changed my password this morning is in that dialog. I was told by vmware tech support on a ticket last month that those credentials were only used on the first connection to ldap.. how wrong he was. It looks like I need to use an account who's password does not change every 90 days!  Putting my new password into that field makes vcenter work just fine with domain accounts!! I don't think rejoining the domain would make any difference.

SSO does indeed play a part in client connectivity.:smileyinfo:

Ron

[npbryant]

I'm having the same issue as vmrulz's original post, but I'm a little confused about where you found success. When I navigate to "edit the identity source", and enter the password for my domain account and select "test connection", I get a pop-up saying "Connection Success. The connection has been successfully". The next thing I do is hit OK on the edit identity source box, and I get an error message saying: The "Edit identity source" operation failed for the entity with the following error message. Error connecting to the identity source ".

Any thoughts?

[vmrulz]

The only thing I can think of is the account your using does not have perms to connect to LDAP in some form or fashion. You would think the TEST Connection button would verify properly. Hopefully the changes in 5.5 will simplify this component of vsphere.

[npbryant]

Thanks for the fast response! I opened a ticket w/ support and will update the thread when we get resolution.