This year, I have been busy upgrading customers from VMware 5.0 to 5.1. Next year promises a flurry of upgrades to VMware 5.5. One significant change in VMware involves how it deals with credentials and integration with Active Directory. New for 5.1 is the Single Sign On (SSO) service and its associated underlying database. This change causes many automated logins to stop functioning, because SSO requires the credentials to be presented as domain\user and will not assume a domain name like its predecessor 5.0 did. Many of the customer sites which have upgraded themselves have repeating login errors and I thought it beneficial to blog about how to find and resolve these errors.
- Check for errors:
- Run the vSphere client
- Navigate to Home | Management | Events
- Highlight the first event in the list
- As you use the down arrow to move events, the “Event Details” below will populate…
- Look for events that begin “Type: error”
- Fix any “Cannot login…” errors:
- Look for a description of “Cannot login user@computer” errors
- Notice that a correct attempt would have been domain\user@computer!
- If the computer name is specified as an IP (like my screen shot), you can use “nslookup IP” to find the FQDN
- User remote desktop, VNC, or SSH to access the computer in question
- Edit the software or scheduled job that is generating the login attempt
- Replace user with domain\user in the login attempt
- Validate the changes:
- Note that you may need to reboot the computer that is generating the login attempt, to restart services
- Go back into the vSphere client
- Navigate to Home | Management | Events
- See if the errors have been replaced with messages in the form “domain\user@computer logged in as…”
The most common programs that need to be edited are monitoring programs that are using the VMware API to provide automated reports, alerts, and statistics. For instance, Solarwinds, Nagios, and Splunk may all need their credentials editing after the VMware 5.1 upgrade.