Had this issue today after upgrading from VCSA 5.5 U3 to 6.6 U1A.

How was the VCSA setup before?

  • DNS servers configured to Prod DNS
  • Time configured to AD servers (automatic when you join the domain from the VAMI)
  • AD configured

Symptoms:

  • Logging into vCenter Server completes successfully with Administrator@vsphere.local
  • AD Users that used to authenticate with vCenter (even Admins) see the following error pop up: “Client is not authenticated to VMware Inventory Service – http://localhost:10080/invsvc”

After looking around, I didn’t see anything that pointed to a specific answer. Also to note, nothing related to vSphere or VCSA 6. A lot of items we found discussed that it was something that was fixed in 5.5 U2. Hmmm.. ok.

Resolution:

  • Since we were using AD for time server because 5.5 U3 VCSA made the AD server the time server, we had no NTP setup in the VAMI. Added the time server and moved on. Oddly for one of our servers, the DNS was missing as well, its odd, but even though it SHOWED the correct DNS servers, when I went to edit the network settings, it was set to automatic. Well that won’t do at all. Set them manually and moved on.

NOTE: Add the vCenter to the root domain if possible, or at least that is what I had to do. If you are adding more than one VCSA to the same domain, with very similar names, read this post as well.

  • Next, I removed any AD Identity sources and then left the domain.
    • If you are unfamiliar with how, first remove the Identity source from Administration > SSO> Configuration > Identity Sources.
    • Then leave the domain from Administration > Deployment > System Configuration > Nodes > {vCenter FQDN} > Manage > Active Directory.
    • Reboot the server after leaving the domain.
  • Once the VCSA comes back up, rejoin the domain:
    • Go back to Administration > Deployment > System Configuration > Nodes > {vCenter FQDN} > Manage > Active Directory, join the domain again.
    • REBOOT! (I know this takes forever, I’m sorry.)
    • Go back to Administration > SSO> Configuration > Identity Sources and add your AD identity source once again.
  • After this is complete, check your permissions and attempt logging in as an AD user.

This fixed it for us, but if you are having worse luck, let me know and I’ll try and work it out with you.