Just registered to say thanks to PJVanMeerbeeck for the solition related to user permissions.
Removing local identity source fixes one problem but it will allow domain users to log in ONLY IF they have permissions granted in vCenter directly to their accounts.
But there is another problem:
If the user is granted access in vCenter via group and the user is not a Domain Admin, then this user won't be able to log in.
As PJVanMeerbeeck stated, this is related to the permissions that service account has regarding reading other user accounts' properties.
For some reason, domain admin accounts have permissions configured on them that allow all authenticated users to read more properties than can be read from a regular account. Thus SSO service account can read required properties like Restrictions and Group Membership from domain accounts. But it cannot get this info for non-Domain Admins users. (this results in "NetUserGetLocalGroups failed: Access is denied." error)
If you give permissions to some "VMUsers" group in vcenter and this group has a domain admin and non-admin account in it, then domain admin would be able to successfully login while non-admin would not.
In my deployment SSO is configured to run under "network service" which means that it will access AD using its computer account credentials.
What I did to fix the problem:
1. Created a group called "Vmware SSO Servers", added vcenter computer to it (SSO and Vcenter run on the same computer) and rebooted the computer so that new group membership applied.
2. Created additional delegation to this group and allowed reading all user properties (on the OU that has in it all user accounts that need access to vCenter).
You can skip step 1 and just delegate these permissions directly to the service account (or VC Computer) that you are using.
Or you can add your service account to the "pre-windows 2000 compatible access" group as it already has access to the required properties. If it is "Network Service', then don't forget to reboot computer for the membership to apply. (as PJVanMeerBeeck has noted, this not good according to the principle of least privilege.
Another thing I'd like to notice, that it is confusing what accounts services run under.
"vCenter Single Sign On" Service runs under local system.
It is VMwareVCMSDS that runs under the account that you configure during installation.
I spent some time trying to run "vCenter Single Sign On" service under Network Service account as I thought that it was an installation bug.
Hope this helps.