Today I found out that in vSphere 5.1 the SSO administrator account (admin@system-domain) has a password that expires after 365 days. See KB2035864:
vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for admin@system-domain.
Awesome.
In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation)
By default, vCenter Single Sign-On passwords, including the password for [email protected], expire after 90 days.
Following KB2034608 to reset the admin@system-domain I came across an interesting error:
My first thought was that the SSL certificate was not valid, or that it didn’t have the IP address but rather the FQDN or server name. I am using SSL certificates signed by my internal Microsoft Certificate Services PKI – I know that the certificate is not only valid but working fine for the lookup services (otherwise the rest of vCenter would also be having problems!) I checked and the certificate has the short name, FQDN and the server’s IP address in the SAN fields.
Quite worryingly, with a bit of searching around I found that most people were recommending a reinstallation of vCenter for this error!
I decided to see if there were any other options to the ssopass command to perhaps ignore the SSL error or manually bypass it, so fired off a guess: “ssopass –?”. I was wrong, you need “ssopass –h” or “ssopass –help” – but the result was the same – parameters:
At first I tried the –t option and pasted the thumbprint of the SSL certificate into the command:
One step forward, but it’s now complaining about the certificate chain – perhaps this is a dead end! The next option I tried was to use the –d option and specify the FQDN of the server, which is the Subject (rather than a Subject Alternate Name or SAN).
Better – at least now there are no SSL certificate errors – just a wrong user name! The final working command was this:
ssopass –d https://vc-01.definit.local/lookupservice/sdk admin
The result is a changed SSO password – look out for the return code “Success”.
It’s definitely worth setting up a second administrative user for SSO admin rights – this would allow you to log on to the SSO administration and reset the admin@system-domain account password. If you’re on a 365 day expiry, creating it 180 days after the admin account is reset would make sense to allow for a crossover.