You are right. I am using Srv 2012. SSO machine is joined to the domain yes. Both the domain controller and vCenter server are 2012. I would love to try the fix you have, that would be great.
Please upload the dll and advise what exactly needs to be done. Thanks a lot for all the tips.
I am having exactly the same issues, but with the appliance.
I did an upgrade vom 5.1 to 5.5.
After that the AD-Auth was not working anymore. I then added the "integrated windows authentification".
The user is added to the group "Administrators".
I get "user or password unknown". I can see success logs at the domain controller for kerberos tickets for my username.
But still can not login.
Patiently waiting on Srinu's fix. Hopefully that will help us out
I could "solve" the issue by using the same configuration as with vsphere 5.1:
- New Identity Source, Type Active Directory as LDAP
- Copied/pasted the DN-fields from AD for Base-DN for users and groups
- ldaps://dc1....ldaps://dc2... with the dc-certs I exported first.
Then I could login with firstname.lastname@example.org...after solving this bugs:
- First error message was "invalid group ... SID-.....".
- After translating the SID to "Domain-Users" I realized this was because my Domain-Users are in the default-OU while the administrative groups I use are in another OU.
- After moving then my domain-users to the specified ou in vcenter I got another error, like "invalided distinguished name...".
This was because of my german domain-Group was "Domänen-Benutzer" and obviously Vcenter cannot work with umlauts here.
- After renaming "Domänen Benutzer" to "Domain-Users" I can finally login.
But, as expected, I can still not "use current logged in user" as "Integrated Windows Authentification" is not working.
Have the same issue!
Workaround that theburnout proposed had helped to partially solve the issue, after login with AD account I have another error "client is not authenticated to vmware inventory service".
I fix issue with inventrory service. I use service from which I run all vsphere services e.g. SSO, Inventroy service and vCenter.
After change inventory service to "local system" account every thing starts to work fine.
I am having the same issue:
"Cannot parse group information"
When trying to login via the web-interface.
Same here Gregorcy, that error comes up via web client. I have not tried the other guy's fix yet. I still would like to try Srinu's fix (replacing the dll which he will provide us with). Lets hang tight.
I am also seeing this problem. I would be happy to test the .dll file.
Will also look into other solutions, but I'm not making AD modifications at this time.
Found the Log File mentioned earlier. I have the AD Source as the Default yet I'm seeing it try to authenticate via vsphere.local
2013-09-25 13:18:33,774 ERROR [IdentityManager] Failed to find nested parent groups of principal [email@example.com] in tenant [vsphere.local]
2013-09-25 13:18:33,774 ERROR [ServerUtils] Exception 'java.lang.IllegalStateException: Invalid group name format for [\Authentication authority asserted identity]'
That is what i saw in my log files as well. Looks like VMware put out 5.5 too fast
So, further testing of this. If I restart the VMware Identity Management Service and only use Windows Session Credentials. I can log in to vCenter from any domain machine.
if I attempt to log in from any non domain added system, say our OSX hosts using the awesome 5.5 built in OSX Web Client. It immediately states it cannot parse group information. Then I cannot log into vCenter from any of the places that worked before until the process is restarted.
When I am successfully logging in use Windows Session Credentials - the log shows:
2013-09-25 13:34:32,868 INFO [IdentityManager] Authentication succeeded for user [firstname.lastname@example.org] in tenant [vsphere.local] in  milliseconds
2013-09-25 13:35:31,087 INFO [IdentityManager] Authentication succeeded for user [email@example.com] in tenant [vsphere.local] in  milliseconds
2013-09-25 13:36:31,143 INFO [IdentityManager] Authentication succeeded for user [firstname.lastname@example.org] in tenant [vsphere.local] in  milliseconds
2013-09-25 13:37:31,284 INFO [IdentityManager] Authentication succeeded for user [email@example.com] in tenant [vsphere.local] in  milliseconds
2013-09-25 13:38:31,212 INFO [IdentityManager] Authentication succeeded for user [firstname.lastname@example.org] in tenant [vsphere.local] in  milliseconds
When I go to the OSX Machine and try to login:
2013-09-25 13:39:11,791 ERROR [ValidateUtil] resolved group name=[\Authentication authority asserted identity] is invalid: not a valid netbios name format
2013-09-25 13:39:11,791 INFO [ActiveDirectoryProvider] resolved group name=[\Authentication authority asserted identity] is invalid: not a valid netbios name format
Hope this helps.
JulcE_ALTSEC -> restarting the VMWare Identity Management Service also "fixes" the AD authentication for me as well. It seems that if I reboot the vCenter server (Windows Server 2012 Standard), I get the AD errors again until I manually restart that service. Very interesting. Hopefully whatever DLL we're waiting on resolves that - not that I restart my vCenter server often. Sorry I can't help with the OSX bit, just wanted to thank you for that help and confirm that it has "fixed" things for me.
As a side note: I also tried installing to 2012 R2 server, but the vCenter Server install gets hung up on "Installing Directory Service".
The same thing that affects my OSX hosts, affects any Windows host not added to the domain.
Just test that as well.
To clarify this issue exists the SSO/vcenter systems which are deployed on win2k12 machine and are joined to a win2k12 domain, and an identity source is setup to use Active Directory with windows authentication and you are using a domain user from the win2k12 domain to login. We are preparing a patch dll which contains the fix and will put up a kb article with the patch dll attached. We will put a kb article which will contain the patch dll with the instructions on how to apply this patch within 12-24 hours. Sorry for the delayed response and thanks for being patient.
Thanks for being patient. Please see the update/comment #28.