Yesterday, I went to a customer for a migration project to vSphere 5.5. After deploying vCenter Server Appliance 5.5 U2d and configuring IP addresses, I logged in with “root” account and default password to begin configuration and I started with adding it to my customer’s AD Domain to adjust its time sync and confirm machine naming and DNS settings. After I added it successfully, I rebooted the vCenter Appliance and once it booted up I tried to log in with “root” and boom, I can’t log in. It threw an error: “Unable to authenticate user. Please try again.”
First, I thought I was writing password wrong, but I wasn’t as I found that I could log in using SSH. Then, I noticed that the time-zone on the appliance isn’t set to mine (Egypt:GMT+2). I thought it may help to adjust the time-zone, and it was another long story that is mentioned here. I tried again after modifying the time-zone but same error: “Unable to authenticate user. Please try again.”
Digging in the logs gave me nothing. I started to search for a community help over Google and here what I found: for some reason after adding my vCSA to AD Domain, and time sync is configured to AD Domain, the “root” password expired and the account is locked on the VAMI UI only. In case you don’t know, beginning from vCenter Server Appliance 5.5, VMware added an expiration policy to “root” password for security concerns and the default period is 90 days and you can find that in this KB. Accordingly, I began to unlock the root account using bash shell cmd “passwd root”. It worked and I could log in.
I found also some great articles related to this issue:
1-) William Lam solved this issue when you can’t log in vCenter Appliance through neither VAMI nor SSH in his article: How to recover VCSA 5.5 from an expired administrator account?. In case you asked, why I didn’t use it, the reason is that I didn’t find the “X” mark he mentioned :D.
2-) In case you use External Windows SSO server with vCenter Server Appliance, you may not be able to log in using “root” account, as Windows-based Local User&Groups or even AD Domain doesn’t include “root” user. You have to create it manually according to this KB.
I hope this helps in solving such issues. It’s so frustrating, I know.