Error connecting to authd on host

[mroach]

When trying to open the console of a guest machine in the desktop version of Infrastructure Client, I get the error "Error connecting to authd on host xxxx"

OS: Vista Business N x64 SP2, fully patched

Infrastructure Client: 2.5.0 build 81946

Server: ESX 3.5.0, 82663

Java: 6 update 14

I'm working from home and connecting to the office with Windows PPTP VPN.

I was previously working from home using XP inside VMware Fusion on my iMac and it worked fine from there. I just tested it again and it still works. I know, silly setup there...

Not sure if it matters, but ESX is setup with Active Directory authentication. Its NTP server is our domain controller; as it also is for my Vista and XP machines. I'm in a different time zone than the server, but so was the XP machine.

I tried disabling the Windows firewall and no luck. I don't think it's that since I'm having no problem with any other LAN services over the VPN.

I tried connecting directly to authd using "telnet <host> 903" and instantly got "220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC"

I also tried the "always use proxy" thing from

Also tried disabling the ESX firewall.

So now I'm out of ideas. Anyone else have any?

[virtuallysi]

You need 902 and 903 open to get a guest console session. See the attached jpg of TCP ports required. Also do netstat -an | find "SYN_SENT" when firing up the console to see if your desktop is unable to connect on any ports.

[mroach]

I can get to both ports via telnet with no problem. I did the netstat thing and SYN_SENT showed up once for a brief second but never appeared again.

[virtuallysi]

If the SYN_SENT reply disappeared we know that TCP was able to connect to the server on all TCP ports so we know its not a firewall rule \ networking issue also that the service is up as it responded. What do your VI client logs say? Is there anything erroring?

Have a look at http://communities.vmware.com/thread/46632

This mentions amending /etc/vmware/config to vmauthd.server.alwaysProxy=TRUE also it mentions removing a registry key for the VI client? HKEY_CURRENT_USER\Software\VMware\Virtual Infrastructure Client\Preferences

[Joshua_Mally]

try restarting the following service on the ESX server:

vmware-vpxa

mgmt-vmware

xinetd

vmware-vmkauthd

-Josh

[mroach]

I tried restarting all of those services, though vmware-vpxa does not exist.

Still no luck. I also tried the proxy thing again and restarting the services I could and again, nothing.

It really feels like something is wrong with my VI Client or destop.

Is the right way to view the VI Client logs to do File > Export > Export Diagnostics Data?

If so, there's nothing useful there either.

[Joshua_Mally]

Is this happening for all the Guest VM's running on the ESX host or for just this VM??

In the diag. reports look for viclient-support folder and vicleint.log file.... hopefully u would something in there that points u to the right direction!!!

[mroach]

It happens for every guest on the ESX host.

I looked at the log files and there is nothing useful in them.

It's just stuff like this over and over again

[viclient:SoapTran] 2009-07-30 16:40:12.753  Start Invoke 42 - PropertyCollector:ha-property-collector.WaitForUpdates ...
[viclient:SoapTran] 2009-07-30 16:40:12.756  Start Invoke 43 - VirtualMachine:384.AcquireMksTicket ...
[viclient:SoapTran] 2009-07-30 16:40:12.888  Finish Invoke 43 - Serial:0,003, Server:000,130 - VirtualMachine:384.AcquireMksTicket
[viclient:SoapTran] 2009-07-30 16:40:16.326  Start Invoke 44 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]527b350d-4988-34ae-972c-2f57002137b5.Destroy ...
[viclient:SoapTran] 2009-07-30 16:40:16.332  Start Invoke 45 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52132bc5-c4dc-056e-bc4c-f947726a1094.Destroy ...
[viclient:SoapTran] 2009-07-30 16:40:16.338  Start Invoke 46 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52d847f6-afa9-567c-28ca-f2a1dc9f69ec.Destroy ...
[viclient:SoapTran] 2009-07-30 16:40:16.437  Finish Invoke 44 - Serial:0,001, Server:000,110 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]527b350d-4988-34ae-972c-2f57002137b5.Destroy
[viclient:SoapTran] 2009-07-30 16:40:16.439  Finish Invoke 45 - Serial:0,000, Server:000,107 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52132bc5-c4dc-056e-bc4c-f947726a1094.Destroy
[viclient:SoapTran] 2009-07-30 16:40:16.445  Finish Invoke 46 - Serial:0,000, Server:000,108 - PropertyFilter:session[526e5880-f052-077b-2c9a-325705be585e]52d847f6-afa9-567c-28ca-f2a1dc9f69ec.Destroy
[viclient:SoapTran] 2009-07-30 16:40:19.011  Finish Invoke 42 - Serial:0,001, Server:006,257 - PropertyCollector:ha-property-collector.WaitForUpdates
[viclient:QuickInf] 2009-07-30 16:40:19.012  WaitForUpdates Version = 12
[viclient:SoapTran] 2009-07-30 16:40:19.012  Start Invoke 47 - PropertyCollector:ha-property-collector.WaitForUpdates ...
[viclient:SoapTran] 2009-07-30 16:40:19.225  Finish Invoke 47 - Serial:0,001, Server:000,212 - PropertyCollector:ha-property-collector.WaitForUpdates
[viclient:QuickInf] 2009-07-30 16:40:20.012  WaitForUpdates Version = 13
[viclient:SoapTran] 2009-07-30 16:40:20.012  Start Invoke 48 - PropertyCollector:ha-property-collector.WaitForUpdates ...
[viclient:SoapTran] 2009-07-30 16:40:36.542  Start Invoke 49 - DiagnosticManager:ha-diagnosticmgr.GenerateLogBundles ...
[viclient:SoapTran] 2009-07-30 16:40:36.673  Finish Invoke 49 - Serial:0,001, Server:000,130 - DiagnosticManager:ha-diagnosticmgr.GenerateLogBundles
[viclient:SoapTran] 2009-07-30 16:40:36.675  Start Invoke 50 - PropertyCollector:ha-property-collector.CreateFilter ...
[viclient:SoapTran] 2009-07-30 16:40:36.685  Finish Invoke 48 - Serial:0,005, Server:016,667 - PropertyCollector:ha-property-collector.WaitForUpdates
[viclient:QuickInf] 2009-07-30 16:40:36.685  WaitForUpdates Version = 14
[viclient:SoapTran] 2009-07-30 16:40:36.685  Start Invoke 51 - PropertyCollector:ha-property-collector.WaitForUpdates ...
[viclient:SoapTran] 2009-07-30 16:40:36.900  Finish Invoke 50 - Serial:0,000, Server:000,225 - PropertyCollector:ha-property-collector.CreateFilter [session[526e5880-f052-077b-2c9a-325705be585e]520e51b4-5e15-6e95-304d-b0f43c81a7db]
[viclient:SoapTran] 2009-07-30 16:40:36.901  Finish Invoke 51 - Serial:0,001, Server:000,215 - PropertyCollector:ha-property-collector.WaitForUpdates
[viclient:QuickInf] 2009-07-30 16:40:36.945  WaitForUpdates Version = 15
[viclient:SoapTran] 2009-07-30 16:40:36.945  Start Invoke 52 - PropertyCollector:ha-property-collector.WaitForUpdates ...
[viclient:SoapTran] 2009-07-30 16:41:33.931  Finish Invoke 52 - Serial:0,002, Server:056,982 - PropertyCollector:ha-property-collector.WaitForUpdates
[viclient:QuickInf] 2009-07-30 16:41:33.932  WaitForUpdates Version = 16
[viclient:SoapTran] 2009-07-30 16:41:33.932  Start Invoke 53 - PropertyCollector:ha-property-collector.WaitForUpdates ...

[virtuallysi]

Have you tried to connect to the VM console via web access? This will confirm if VI client is the root cause of your problem

[mroach]

Oh, indeed I have. That was riddled with failure.

Firefox: Failed to install the plugin

IE: Crashed

Safari: Not compatible

[virtuallysi]

Looks like your desktop build is the root cause of these problems.

[Starman2112]

Hi,

I am having similiar problems connecting to my ESX 3.5 infrastructure from the VI client or web ui. I am getting the error connecting to authd on host xxx.xxx.xxx.xxx

. Until recently I have been able to connect through the VI Client and

web ui. Nothing on the ESX server has been changed or updated. I am

running ESX on a Dell PowerEdge server with no attached SANS,

...etc. I am running ESX 3.5.0 build 64607 and VI client 2.5.0 build

64192. Virtual Center is not installed. The server and desktops are on

the same subnet. I have restarted the services associated with vmware:

mgmt-vmware, xinetd, and vmware-vmkauth. There are no reported errors

with these services. They start fine. I have successfully telneted to

port 902 and 903. I am able to ping the host through FQDN or IP

address. I can RDP to vmware image and access it. I can access the web

pages being hosted from the image.

I have tried different laptops to connect through the client and

web interface. I get mixed results. Some of the laptops were able to

connect through the client and web ui and others get the same authd

error. This leads me to believe that something on the laptop(s)(Microsoft) are

causing my issue. All of the laptops are using Windows XP SP2, IE 8,

.net 3.5 sp1. I have tried to find dll's that are different in version

#, but nothing has surfaced. Has anyone had problems with other

software on their laptops or desktops that host the VI client and

prevent it from viewing the vmware client console?

Any help would be greatily appreciated.

Thanks!!

[ARCcgi]

I also tried the "always use proxy" setting with no joy.

I am using Windows 7 x64. For grins, I ran compatiability check and set to use XP SP2 and the Client now works great.

Hope that could also help someone else, since this case is rather aged, but still Google finds it at the top of the list.

[zalexua]

The true cause of the problem is detected.

My configuration: Windows XP SP3, VMware-viclient3.5u5 (VIC 2.5.0 Build 204931)

On my workstation, set a wide variety of software, perhaps you do the same thing:).

It was found that the client VpxClient.exe strange loads some DLL libraries (libeay32.dll ssleay32.dll)

My problem was due to the fact that I had installed php-5.3.2-Win32-VC6-x86.msi

After starting the VIC when i trying to open the console, loaded libraries (libeay32.dll ssleay32.dll)

Due to the fact that I have a folder c:\PHP\ have these files in the environment variable Path registered there way, the client VpxClient.exe loads libraries from there and we have the error. Process vmware-remotemks.exe not even start.

If i remove the "c:\PHP\" from the Path environment variable, then the problem disappears. Even though that is used in my particular case, a library of OpenVPN :). You may be the way that other realties.

Thanks to Mark Russinovich for the excellent Process Explorerutility and of course the divine Wireshark, which prompted to begin to look for the cause of the problem.

Good luck, I hope my troubles to anyone at will.

[chadj]

Thanks zalexua,

This fix worked for me.

I had installed PHP as well. And once I removed the c:\PHP5 from my path and did a restart of my computer, I was able to connect to my virtuals.

[ckaye]

Thanks zalexua !

This has been a problem for me for a wile!  I would never have found this!

[ErnestoTHernand]

Wow nice find zalexua.  I had the same issue except it was related to Nmap and not PHP.  Nmap (or zenmap) apparently sets itseful up in the user path.  Using your same technique, I was able to discover that, remove it from the path and viola!  VI Client works again!

It took me a second to find the DLLs view in Process Explorer (View > Lower Pane Views > DLLs), and then you need to add the Path column to the DLLs view.  But after that it was pretty simple.  Again, well done.  That's hugely helpful.

[DC1]

Hello

I have had this error recently with VIC  2.5.0.64258

In the registry under HKEY_CURRENT_USER\software\Virtual Infrastructure Client I renamed "preferences" and restarted the VIC.

All is now working without any problem

Regards

Dermot C

[ErnestoTHernand]

@Dermot:

That's likely only a temporary solution.  You can delete the entire registry key and have it work once.  If you close the app and then run it again, you'll likely run into the authd issue all over again.  I'm not really sure how the registry key relates to the other dlls in the path, but the only permanent solution for me was to remove the conflicting DLLs from the path with a little detective work in ProcessExplorer per zalexua's post.