vCenter 5.1 and AD authentication issues

[andrey_paramono]

Hello,

A little bit of intro:

1. VC5.1, SSO, Inventory and Web Client installed on a single VM (clean installation).

2. MS SQL is installed as a separate VM

3. During installation of SSO an AD connector was successfully created

4. During VC installation "DOMAIN\VM Admins" group was assigned as a "admin" group.

5. "DOMAIN\VM Admins" group is listed as assigned "Administrator" privileges for "This object and its children" in VCenter -> Host & Clusters > Manage

> Permissions.

6. AD account which is a part of "DOMAIN\VM Admins" can successfully login to Web client and to GUI client

2 problem scenarios:

1. a) create a simple user,

    b) add it to "DOMAIN\VM Admins"

     => user CAN login to web client ONCE. After logout any consecutive tries give "Provided credentials are not valid." error

2. a) create a simple user

    b) add it as "Administrator" on the same level as "DOMAIN\VM Admins" group is assigned to.

    => Any login attempt gives "Provided credentials are not valid." error

Looks like SSO/Inventory service issue, but fiddling with SSO access administration (adding users to LSAdministrators, __Administrators__ etc groups) doesn't seem to provide any relief.

Any help/suggestion is appreciated.

[andrey_paramono]

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....

[Sinosh]

we also got some problems after upgrade to 5.1, single domain user can login but the domain group does not work...ref my post http://communities.vmware.com/thread/419540?tstart=0 

[andrey_paramono]

Update:

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.

[vrm]

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.

[SimonBernCH]

Hi all

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.

Simon

[SimonBernCH]

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.

[kattrap]

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.

-Andrea

http://vkoolaid.blogspot.com/2012/11/vcsa-51-sso-ldap-issues.html

http://vkoolaid.blogspot.com/2012/11/vcsa-sso-secret-active-directory.html

[JimKnopf99]

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. :smileyangry: :smileyangry::smileyangry:

I do not upgrade to the new Version until they are getting the sso stuff to work

Frank

[KenySchmeling]

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 (aasilva@demarest.com.br - 11-3356.1637) ou Gabriel Nonato (gnonato@demarest.com.br - 11-3356.2028).

Grato,

Keny Schmeling

Keny Hayakawa Schmeling | Demarest e Almeida

kschmeling@demarest.com.br