So far no luck. I opened a support case regarding this issue; I see that there are many SSO troubles being reported
At least a couple of logs can pinpoint the issue, but no solution yet:
2012-09-21 17:31:09,665, [castle-exec-144], (PrincipalHandlerBase.java:67), trace.com.rsa.ims.authn.HandlerBase, INFO, V
CD-XX-VC.domain.local,,,,The principal with ID: cloud38 is disabled. Reason: ReasonKey[AUTHN_PRINCIPAL_DISABLED]
PS. User is not disabled in AD....
It seems that the only proper way to install vCenter SSO is to do as following
1. Create AD service account
2. Add it to Local Admins on a box where SSO is being installed
3. Install SSO and specify the user created in 1) to run the service.
With that method SSO installer/service discovers all the Active Directorie(s) and then able to properly work with all the identity sources.
Here's comparison of working and non-working SSO difference:
Item Non-woking Working AD LDAP Connection ldaps://server.address ldaps://server.address:3269 Authentication Password Reuse Session
For the record, setting to "working" configuration on a "broken" SSO installation does not do any good - neither restarting SSO service nor rebooting the box itself helps.
My final conclusion that this issue has to do with initial installation and AD discovery. Once AD is not properly discovered (Error 29155 Identity source discovery error) during installation, nothing can help. VMWare KB 2034374 (kb.vmware.com/kb/2034374) suggests to go ahead and add identity source later but it seems non-working solution.
We had the same issue in our testlab, only we changed Resuse Session in Password and add an default domain user account for authentication to workaround this issue. Now all AD users add to the vCenter roles & permissions can login to vCenter. I'm interested in the "VMware best practice" authentication method and "security" differences between Reuse Session and Password.
UPDATE: This is not the solution.
We have exactly the same problem:
- User with direct permission on a folder/vm/rp... work perfectly with "Use Windows Session Credential" in the vSphere Client
- User with direct permission on a folder/vm/rp... do not work with manually entered credentials in the vSphere Client
- User which are in a ad-group and the group is permittet on a folder/vm/rp... do not work at all
Tried installing a test-vcenter, test-esxi, test-sso ..... without success.
We specially made a AD-Service Account to deal with the SSO, still no success.
Attached the imsTrace Log "anonymized".
I will open a Ticket at VMWare.
imsTraceAnon2.log 188.8 K
I opened a case @ VMWare, they suggest it is only a permission problem of the service account, I do not agree, tested with various permissions and varios login possibilites, still groups and not "reuse session" logins fail.
Answer from VMWare which does NOT work:
In the case where an administrative account was not allowed to be used for security or
policy reasons, you may use a service account instead. If a service account is used, the
permissions of the service account must be such that this service account is able to read
the properties and attributes of any user which you intend to have login capabilities in
vSphere. If the service account cannot read these attributes, the logins will fail.
The solution is to increase the permissions on this service account such that it is able
to read all user attributes. Please give the service account domain admin rights.
I whish the old vCenter without this SSO-Stuff would come back.
Domain admin rights for a service account? Don't follow down that rabbit hole...
SSO with ldaps on port 636 (not global catalog port 3269) with a default domain user service account worked while reuse session kept erroring out when attaching to my domain.
To make sure that my DNS and ldap strings were correct I temporarily allowed straight ldap to our domain with a GP change.
I have the exact same issue for some users.
Some work while other not..... And all have the same permissions.....
I am so pi* of about the sh* of that installation i could not tell you.
I do not upgrade to the new Version until they are getting the sso stuff to work
Estarei ausente no escritório no período de 15/11/2012 à 16/12/2012, sendo assim, solicito que qualquer dúvida ou e-mail importante seja encaminhado aos cuidados de Anizio Almeida (email@example.com - 11-3356.1637) ou Gabriel Nonato (firstname.lastname@example.org - 11-3356.2028).
Keny Hayakawa Schmeling | Demarest e Almeida