The problem on our side was that the service account did not had enough rights for querying the users in AD. In the audit log on AD I noticed that the service Account was missing read permissions on tokenGroups attribute and Account Restrictions propertys set.
Afther granting these permissions on AD we had still the same problem. but no extra aduit failures were logged in AD. If i made the service account member of the "pre-windows 2000 compatible access" group the problem was solved, users coula login to vCenter. This is not a desired configuration cause, this way, the service account got a lot of acces rights in AD and according the principle of least privilege I only give service accounts the rights needed/used.
Anyway to make a long story short. The service account was missing read acces on the "member of" attribute of the users who wanted to login to vCenter. granting this read rights solved the problem. probaly because vCenter uses the ms-smar function "openuser" with a desired acces of
USER_READ_GROUP_INFORMATION or USER_LIST_GROUPS, cf. http://msdn.microsoft.com/en-us/library/cc245476.aspx,
The lack of this right in AD was not logged in the audit logs on AD.
I don't see how a local identity sources interferes with this problem.
.
We are probaly not talking about the same problem. I thought the problem was related because of the phrase
"Putting the user in the 'Domain Admins' group allows the user to successfully log-in to both vSphere and web clients"
What kind of rights has your service account in your AD environment?
My reply was mainly a reaction on http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2037546
wich resulted in the same error log
com.rsa.common.UnexpectedDataStoreException: Unexpected Local OS exception
Caused by: com.rsa.ims.localis.LocalisAccessError: Local O/S Identity Source Error: LOCALIS_STATUS_INTERNAL, extended error: 5 : [GroupInfo.c:254] NetUserGetLocalGroups failed: Access is denied.
As in the first post.
Regards,