vCenter SSO changes when demoting domain controller

I’m still getting used to the important part vCenter SSO (Single Sign-On) is playing in vSphere 5.1. In my home lab I was switching domain controllers from W2k8 to Windows 2012. Transferred FSMO roles, integrated DNS, changed IP addresses for DNS on all servers and all seemed fine. My w2k8-dom01 server was demoted and removed. Few days later when trying to make a vCenter connection, I couldn’t logon anymore. As a good Windows Admin I of course first rebooted the vCenter VM but (as all real admins know) that seldom fixes the issue. Diving in the vCenter log files at “C:\ProgramData\VMware\VMware VirtualCenter\Logs” I found the following error:

2013-01-27T10:46:20.302+01:00 [04304 info ‘[SSO][SsoAdminFacadeImpl]’] [FindPersonUser] 2013-01-27T10:46:20.427+01:00 [04304 warning ‘Default’] Warning, existence of user “VANZANTEN\Administrator” unknown, permission may not be effective until it is resolved. 2013-01-27T10:46:20.427+01:00 [04304 error ‘Default’] The user account “VANZANTEN\Administrator” could not be successfully resolved. Check network connectivity to domain controllers and domain membership. Users may not be able to log in until connectivity is restored. 2013-01-27T10:46:20.427+01:00 [04304 error ‘Default’] [ACL] Adding unresolved permission for user “VANZANTEN\Administrator” 2013-01-27T10:46:20.427+01:00 [04304 info ‘[SSO]’] [UserDirectorySso] GetUserInfo(VANZANTEN\vSphereAdminGroup, true) 2013-01-27T10:46:20.427+01:00 [04304 info ‘[SSO][SsoAdminFacadeImpl]’] [FindGroup] 2013-01-27T10:46:20.536+01:00 [04304 warning ‘Default’] Warning, existence of group “VANZANTEN\vSphereAdminGroup” unknown, permission may not be effective until it is resolved. 2013-01-27T10:46:20.536+01:00 [04304 error ‘Default’] The group account “VANZANTEN\vSphereAdminGroup” could not be successfully resolved. Check network connectivity to domain controllers and domain membership. Users may not be able to log in until connectivity is restored.

That is when the lightbulb in my head went on (hey it was Sunday morning and I didn’t have my coffee yet).  I figured the vCenter SSO (Single Sign-On) service was still trying to talk to the old domain controller for authentication, so I opened the administration page of SSO:  https://<your SSO server>:9443/vsphere-client/ Login with:  admin@system-domain  (or root@system-domain for the vCenter Server Appliance). You did write down that password, did you? Go to: “Sign-On and Discovery” -> Configuration and look at the identity sources. There it is, the reference to the old domain controller. vCenter SSO configuration

Change vCenter SSO domain controller

Changing it is easy, click “Edit identity source” and change the name of the new domain controller. Test your settings and you would expect to be done then. vCenter SSO edit identity source

Unfortunately I received the following error: “The edit identity source operation failed for the entity with the following error message. Cannot connect to one or more of the provided external server URLs: w2k8-dom01.vanzanten.local:389”.

vCenter SSO identity source failed

Strangely enough it is still pointing at the old domain controller. The easiest way to solve this was to just delete the entry and create a new one with the new domain controller in. Just to be sure I restarted the vCenter SSO (Single Sign-On) service first and then vCenter Server would start without any issues.

Update:

In the comments on this post, Jad (JM) wrote that you can also use the domain name when entering the primary server URL. In my case I would NOT enter: “ldap://w12-dc01.vanzanten.local” as my Primary URL but just “ldap://vanzanten.local”. vCenter SSO will then query the domain for the special domain controller DNS record and use this to find the domain controller to talk to. Btw, this doesn’t work if you already have entered two URLs and want to change them and make the second one empty. Think it is purely a GUI issue. When I empty the second URL, save it and then edit to check again, it keeps the old entry. When you delete the whole entry and create a new one that has an empty secondary URL, you’re fine. Thanks Jad!