vSphere client login problem

[Bart_Verbruggen]

Since the upgrade of vSphere server from version 5.0 to 5.1 some users are no longer able to login, but the vSphere web client works fine.

They get the error: The server 'xxx' took to long to respond. (The command was timed out as the remote server was taking too long to resond.)

The client log file shows this:

at VirtualInfrastructure.ManagedObject.InvokeMethod(MethodName, Object[])
   at Vmomi.SessionManager.LoginBySSPI(String, String)
   at VmomiSupport.VcServiceImpl.LoginBySSPI(LoginSpecInternal2)
   at VmomiSupport.VcServiceImpl.Login(LoginSpec)
   at VirtualInfrastructure.LoginMain.Process(BackgroundWorker, DoWorkEventArgs)
   at VirtualInfrastructure.LoginWorkerImpl.Worker_DoWork(Object, DoWorkEventArgs)
...
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
[viclient:Error   :P: 3] 2012-09-18 10:06:52.925  RMI Error Vmomi.SessionManager.LoginBySSPI - 5
<Error type="VirtualInfrastructure.Exceptions.RequestTimedOut">
  <Message>The request failed because the remote server 'esxvc02' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)</Message>
  <InnerException type="System.Net.WebException">
    <Message>The command has timed out as the remote server is taking too long to respond.</Message>
    <Status>Timeout</Status>
  </InnerException>
  <Title>Connection Error</Title>
  <InvocationInfo type="VirtualInfrastructure.MethodInvocationInfoImpl">
    <StackTrace type="System.Diagnostics.StackTrace">
      <FrameCount>17</FrameCount>
    </StackTrace>
    <MethodName>Vmomi.SessionManager.LoginBySSPI</MethodName>
    <Target type="ManagedObject">SessionManager:SessionManager [esxvc02]</Target>
    <Args>
      <item></item>
      <item></item>
    </Args>
  </InvocationInfo>
  <WebExceptionStatus>Timeout</WebExceptionStatus>
  <SocketError>Success</SocketError>
</Error>
[viclient:Critical:M: 7] 2012-09-18 10:06:52.940  Connection State[esxvc02]: Disconnected
[viclient:SoapMsg :M: 7] 2012-09-18 10:06:52.940  Attempting graceful shutdown of service ...
[viclient:SoapMsg :M: 7] 2012-09-18 10:06:52.956  Pending Invocation Count: 0
[viclient:SoapMsg :M: 7] 2012-09-18 10:06:52.956  Graceful shutdown of service: Success
[        :Error   :M: 7] 2012-09-18 10:06:52.956  Error occured during login
VirtualInfrastructure.Exceptions.LoginError: The server 'esxvc02' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
   at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
   at VirtualInfrastructure.LoginWorkerImpl.Worker_DoWork(Object sender, DoWorkEventArgs e)
...
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
VirtualInfrastructure.Exceptions.RequestTimedOut: The request failed because the remote server 'esxvc02' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
   at VirtualInfrastructure.Soap.SoapServiceWrapper.DoInvokeSync(ManagedObject mo, MethodName methodName, Object[] parameters, Int32 timeoutSecs)
   at VirtualInfrastructure.Soap.SoapTransport.VirtualInfrastructure.Transport.InvokeMethod(ManagedObject mo, MethodName methodName, Object[] pars)
   at VirtualInfrastructure.ManagedObject.InvokeMethod(MethodName methodName, Object[] pars)
   at Vmomi.SessionManager.LoginBySSPI(String base64Token, String locale)
   at VmomiSupport.VcServiceImpl.LoginBySSPI(LoginSpecInternal2 loginSpec)
   at VmomiSupport.VcServiceImpl.Login(LoginSpec loginSpec)
   at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
System.Net.WebException: The command has timed out as the remote server is taking too long to respond.

In my vpxd.log file I see at the same time:

2012-09-18T10:06:53.036+02:00 [11704 error 'SoapAdapter.HTTPService'] HTTP Transaction failed on stream TCPStreamWin32(socket=TCP(fd=16104) local=127.0.0.1:8085,  peer=127.0.0.1:59602) with error class Vmacore::SystemException(An established connection was aborted by the software in your host machine. )

Someone knows how to resolve this?

Thanks,

Bart

[iw123]

Is it any different if you use the IP address rather than the hostname?

[swilke]

Same issue here.  Were you able to resolve it yet?

[GRerink]

Here same problem.

But unfortunately all vSphere clients have same issue.

Anybody an idea?

[OldGreg]

Same here, although the issue is intermittent.

[rewalt]

Same problem here. It worked for one day after the upgrade to 5.1, then stopped. It does not matter if I try it locally on the vCenter server or remotely. It also does not matter if I use FQDN, IP, localhost...

I hope this is solved quickly because we have a lot of people depending on vCenter access!

[pascalsaul]

I'm also facing exactly the same problem and it's getting really annoying now. I'm having more luck when I logon with a domain account where vCenter also belongs to. Authenticating with user accounts from external domains is giving even more problems. Thereby I notice also a difference when I use the web client or fat client. I'm having more succes with the web client then fat client, so odd! VMWare can't give me a proper answer or solution yet. I wonder if somebody has some more luck in the mean time?

Did anyone reviewed: http://kb.vmware.com/kb/1032641

[BilBens]

I had a similar problem from version 4 to 5. I downloaded and installed the new version of vSphere Client and pb is solved.

[pascalsaul]

I guess everybody is running the latest version of the client

[pascalsaul]

http://kb.vmware.com/kb/2035510

Just had contact with support about this issue and found out the "Use Windows Session Credentials" doesn't work always with SSO. Just type your credentials manual can solve the issue

Thereby be sure to follow http://kb.vmware.com/kb/2035510 when adding external domains. After that, add the trusted domains to the default domains and reorder the domains to suit your needs and SAVE (yes, really important)!

[infopoint]

I was getting intermittent problems with logging in as well. I only have 2 hosts (HP DL360 G5) and about 20 VMs. I am running vCenter Server in a VM and I found that if I increase the amount of memory assigned to the VM to 8GB, I rarely get the timeout error. From comparing the install guides, it seems with the addition of the web client server component and the increase in memory requirements from the other components, if you're running everything on the same VM, as I am, then this is probably the minimum required for it to work reliably.

If anyone knows of a way to adjust the timeout requirements, I would rather do that than assign more memory. I am fine with it being slow as long as it actually connects. I am also looking at the vSphere appliance but it looks like that one is assigned 8GB by default as well.

-Nick

[tedmid]

We had the same issue you describe where the legacy client cannot use the window session credentials checkbox.

Try the following:

1. Login to SSO, via web client, using admin@system-domain user.
2. Under Administration > Sign-On and Discovery > Configuration > Edit the Identity source for the Domain.
3. Change your Primary Server URL for your domain from secure LDAP to Standard by changing the URL and port number.

Before:

Secure Global Catalog address: ldaps://<global_server>:3269

After:
Global Catalog address: ldap://<global_server>:3268

-ted

[kamalive]

Thank you Ted!! Your suggestion solved my issue. This is exactly what I was looking for.

[CTAHOK]

I am facing the same issue and using latest vCenter Server and a vSphere Client (all in the same Windows 2008 physical box, including SQL 2005 SP4). I do not use secure LDAP so this is not a solution for me. The only thing I noticed is even logging via web client is slow and takes approx. 5-10 minutes for a domain user, admin@system-domain logs in relatively quicker. Please advise.

[Bart_Verbruggen]

Got feedback from VmWare support.

They confirmed me that there is a bug in the SSO.

When you have a lot of AD groups in your kerberos token you get the login problem.

This bug will be fixed in version 5.1.0b. This version will be released around august 2013 according to VmWare support.

Let's hope this will fix the login issue.

[CTAHOK]

Thanks Verbruggen for your reply.

5.0.1b version of what SSO subcomponent or vCenter itself?

[Bart_Verbruggen]

VMware vCenter Server 5.1.0b.

[CTAHOK]

vCenter 5.1.0.b was released on 20.12.2012 and we are using vCenter Server 5.1 Update 1a (released on 22.05.2013.)

The issue was resolved by modifying Base DN Group in identity source of for the AD. So I changed the source from DN=DOMAIN,DN=LOCAL to CN=BULITIN,DN=DOMAIN,DN=LOCAL and this worked fine.

Note to VMware: This clearly a bug as I was able to log in using vSphere Web Client but was not able with vSphere Client.

P.S.

I must say the Base DN for Users was CN=Users,DN=DOMAIN,DN=LOCAL and our Users OU have had more than 18 000 objects listed which may caused the timeout. But why did not webclient timeout then?

[joelgibson]

Thanks CTAHOK. That solution got me going in the right direction. It would seem to me that the length of the time out is different between the web and thick client.

In my case, I was able to resolve the issue in my environment (vCenter 5.1.0 Build 1123961) by modifying the Base DN for users and groups to: OU=<ORGUNIT>,DN=<DOMAIN>,DN=<LOCAL> (where ORGUNIT, DOMAIN, and LOCAL are replaced with environment specific details).

[RicanoR]

I Ran into this issue also with a Single host after I shut it down in Maintenance Mode to move it to a new power supply completely.  When I powered it back up I could not login with the root account to the vSphere Client (no vCenter).  I was able to ssh to the client and even after restarting all agents and rebooting the host a second time I could not login.  However I was finally able to login with AD credentials domain\user password without any issues.  Weird as all my VMs including the AD servers were offline on the host, but it worked.  Hope this helps!