Unable to log into VMware vCenter Server after upgrading to vCenter Server 5.1

Products

VMware vCenter Server

Issue/Introduction

Symptoms:

After an upgrade to vCenter Server 5.1 is complete, you are unable to log into vCenter Server.
When you attempt to add Local Operating System as an Identity Source, you see the error:

Invalid local OS domain details : Cannot configure a Local OS Identity Source on a Linked Mode Replication Instance
From the vSphere Client, you receive this error:

You do not have permission to login to the server: <VC server>
During the installation process, if it is detected that you are losing these permissions, you are prompted with:

This operation will delete existing vCenter Server users that do not exist in vCenter Single Sign On. These users are listed in the file deleted_vc_users.txt, in the system temp folder. These users will no longer be able to authenticate to vSphere. Do you want to keep these users in the vCenter Server database? <yes> <no>
When installing vCenter Server 5.1.0a, you may be prompted with the these messages:

In the vCenter Server database, users or groups were found that are not recognized by vCenter Single Sign On. These users or groups admin permission will be deleted from vCenter Server database. These users are listed in the file deleted_vc_users.txt, in the system temp folder. These users will no longer be able to authenticate to vCenter Server.

In the vCenter Server database, no users or groups were found that have admin privileges and are also recognized by vCenter Single Sign On. In the next panel, enter the users or groups that you will use to log in to vCenter Server with admin privileges.

In the vCenter Server database, users or groups were found that have admin privileges and are also recognized by vCenter Single Sign On. These users are listed in the file vc_admin_users_groups.txt, in the system temp folder. Use these users or groups to log in to vCenter Server.
The imsTrace.log file (located at VC Installation Directory\SSOServer\logs\ imsTrace.log), contains errors similar to:

11:00:25,584, [name], (UserNamePasswordPlugin.java:68), trace.com.rsa.riat.ws.security.trust.authn.impl.UserNamePasswordPlugin, DEBUG, VCENTER1.domain.com,,,,Inside UserNamePasswordPlugin
11:00:25,584, [name], (IMSUtilImpl.java:341), trace.com.rsa.riat.utils.IMSUtil, DEBUG, VCENTER1.domain.com,,,,Looking up user: username@domain
11:00:25,584, [name], (IdentitySourceAccessSQL.java:1310), trace.com.rsa.ims.admin.dal.sql.IdentitySourceAccessSQL, DEBUG, VCENTER1.domain.com,,,,SELECT ID FROM IMS_IDENTITY_SOURCE WHERE (UPPER(DOMAIN_NAME) = UPPER(?) OR UPPER(ALIAS) = UPPER(?))
11:00:25,584, [name], (IMSUtilImpl.java:352), trace.com.rsa.riat.utils.IMSUtil, ERROR, VCENTER1.domain.com,,,,Domain name or alias cannot be resolved: domain.corp com.rsa.common.DataNotFoundException: Identity source not found for the specified domain/alias: domain at com.rsa.ims.admin.dal.sql.IdentitySourceAccessSQL.lookup

Environment

VMware vCenter Server 5.1.x

Cause

VMware vSphere 5.1 introduces a new authentication method, Single Sign-On, and during the install it may have removed permissions for local identity sources. This results in users being unable to log in.

The Single Sign-On installation may fail to detect the domain for the vCenter Server users and prevent it from adding the Active directory (AD) domain as a valid identity source to allow those users to log in.

This commonly occurs if Single Sign-On is installed as a multisite/HA installation. Local OS sources are not used for authentication. This prevents any users you have set up on the local OS access into vCenter Server from logging in.

Typically, the local OS group Administrators is removed. This means they can no longer log in due to this being a multisite installation, even if they are kept in the database.

Resolution

This issue is resolved in VMware vCenter Server 5.1 Update 1. For more information about this version, see the VMware vCenter Server 5.1 Update 1 Release Notes. You can download the latest release from the VMware Download Center.

To work around this issue when you cannot upgrade, specify port 3268 as the Primary Server URL.

To specify port 3268 as the Primary Server URL:

If you have not already done so, install the Web Client.
Log into the Web Client as admin@system-domain.
Navigate to Administration > Sign-On and Discovery > Configuration.

Note: The screen is split into two sections with Identity Sources above and Default domains below.
Under Identity Sources, verify that your domain is listed as a valid identity source.
If your domain is not listed, add the domain:

Click the + (green) symbol and enter the required information. For example:
- Name: Any name you want to refer to this Identity source as (typically the domain name)
- Primary Server URL: ldap://domain_server_FQDN:3268
- Secondary Server URL: optional
- Base DN for users: DC=domain,DC=int
- Domain Name: Domain_Name_or_FQDN
- Base DN for groups: DC=domain,DC=int
- Authentication Type: (How you want to authenticate the initial connection to your domain)
Caution: Specify the port 3268 for the Primary Server URL, which otherwise defaults to port 389. Allowing it to default to port 389 may impact log in via SSO.
Test the connection to verify connectivity.
Click OK to save the identity source.

Notes:

Log in may also fail if an AD domain group has a nested group from a child domain. To resolve this issue, specify the child domain directly within vCenter Server instead of nesting the group within another group.
In cases where the domain is listed, move the domain to the top of the list in the Default Domains window.
Your users in AD may now be able to log into the vSphere Web Client using AD credentials. Be sure they specify domain\user in the login prompt.
If the AD domain exists as a valid Identity, you may have basic permission issues within vCenter Server.
If users/groups were specified within the Local OS as members of the Administrators group, these users will also have lost access to log into vCenter Server. The user specified during the install as the vCenter Server administrator should then be able to log into vCenter Server and grant permissions to the vCenter Server object as an administrator to allow the users to log in again.
Verify that there is an alias listed in the identity source.

Additional Information

To be alerted when this document is updated, click the Subscribe to Article link in the Actions box

For more information, see:

Impact/Risks:
Caution: Specify the port 3268 for the Primary Server URL, which otherwise defaults to port 389. Allowing it to default to port 389 may impact login via SSO.