I realize this is an old thread, but having recently run into a similar error that was somewhat tricky to solve, I thought would reply. I've run into this account lockout problem twice, under completely different circumstances, for my user account after updating my AD login password. The vpxd.log would show repeated entries similar to below (domain\user changed to protect the guilty :smileyhappy: ):
[2012-02-20 08:46:49.367 04884 info 'App' opID=477a53e0] [VpxLRO] -- BEGIN task-internal-8441 -- -- vim.SessionManager.login -- 2E7A86B3-3689-4A70-AB39-F80CDD3047FD
[2012-02-20 08:46:49.371 04884 info 'App' opID=477a53e0] Error 1909 authenticating user domain\user_account.
[2012-02-20 08:46:49.371 04884 error 'App' opID=477a53e0] Failed to authenticate user <domain\user_account>
[2012-02-20 08:46:49.371 04884 error 'App' opID=477a53e0] vim.fault.InvalidLogin
The net result was a continual lockout of the AD account listed above. Using the Windows Resource kit tool eventcomb, we were able to look thru the AD controllers to pinpoint the offending source. Once we had that, we traced it back to one of our VirtualCenter boxes. After trying the usual troubleshooting, i.e. ensure no stale RDP/VC sessions, scheduled tasks, services set to Logon As, etc, there was nothing turning up. The only correlation was to Vcenter server-the account was only getting locked out when the vpxd service was running. After stopping the service and unlocking the account, it would remain unlocked until the vpxd service was restarted and then-bam! Account locked out again.
__
Long story short, there were two cuplrits at work. The first was VCO. We use it extensively in our environment. When you install and config various elements, you have to supply AD credentials. For the Update Mgr plugin config on one VCO server, it had been configured and then removed, but the VCO service had not been restarted-net result, the VCO server was attemtping to connect to the VC server every 30 seconds, and promptly locking out the user account with 4625 events recorded in the VCO server security log. Oddly enough, it was only until we reinstalled the plugin and restarted the service, did it stop this behavior. It almost seemed as if it got 'stuck' in this in-between state.
__
The second was with Quest vFoglight, specifically the Foglight VMware Collector service. This one was a bit tougher to figure out, as it didn't occur every 30 seconds like the VCO related issue. The agent was apparently installed some time ago and not removed but was not started until a recent system reboot, and it would periodically lock out the user account. Looking in the Quest collector.log file, you could see the following error:
012-02-17 20:44:03,506 [7] INFO Collector - GetInventory - Enter InventoryService.GetInventory
2012-02-17 20:44:03,506 [6] INFO Collector - GetFreshInventoryWorker - Enter InventoryService.GetFreshInventoryWorker
2012-02-17 20:44:04,653 [6] ERROR Collector - GetFreshInventoryWorker - Error in InventoryService.GetFreshInventoryWorker: Vizioncore.Vmware.Vim.LoginFailedException: Could not log in to [https://10.10.10.1/sdk/vimService] as domain\user ---> System.Web.Services.Protocols.SoapException: Cannot complete login due to an incorrect user name or password.
This would be generated each time the Foglight VMware Collector service was restarted, and it would also record the 1909 errors in the vpxd log.
Two very different situations, but each very annoying. Since they were both connecting to the VC and then VC was authenticating to AD, made it a bit tougher to resolve then the typical AD lockout situations. Perhaps this will be of help to someone.