Hi
We have installed vcenter 6.0 on windows 2012r2 for couple years. Recently AD DC have upgraded from 2008 to 2016 (without forest level up for now, so it is still 2008 level). I've noticed AD auth on vmware web client was broken with message as in topic name: Client is not authenticated to VMware Inventory Service - http://localhost:10080/invsvc.
If I login as vsphere.local\administrator, then everything is working as supposed. At the same time AD users can login desktop vmware client without any issue.
The issue is the similar to this thread Client is not authenticated to VMware Inventory Service - http://localhost:10080/invsvc
https://vsential.com/2013/11/18/sso-issue-using-windows-server-2012-ad-identity-sourceUnfortunately, there are no solution for me.
First of all, I've tried simple to completely restart vcenter vm - no luck. I've started digging logs and found some errors:
From vmware-sts-idmd.log:
[ActiveDirectoryProvider] obtainDcInfo for domain [NT AUTHORITY] failed Failed to get domain controller information for NT AUTHORITY (dwError - 1212 - ERROR_INVALID_DOMAINNAME)
From inv-svc.log
com.vmware.vim.query.server.ssoauthentication.exception.InvalidUserException: Domain does not exist: NT AUTHORITY
I dont understand where Vmware get this NT AUTHORITY...
Besides I've tried to remove the AD ID source, then re-add it back - no luck. Then I give a try to rejoin vcenter VM to AD (with new SID creation) - no luck. Also I've found on google this: https://vsential.com/2013/11/18/sso-issue-using-windows-server-2012-ad-identity-source
didn't work for me either (
Any one see similar problem? Any suggestions how to fix this?
Instead of full IS reset in 6.0 and later it's possible to reset individual providers.
You can read about them in the following article VMware Knowledge Base
Thanks for the clarification.
I've read this article some time ago. I didn't find an info how to reset for the AD provider. Can you help me with this? Could it help?
I only see the difference between those two options in scenario when you have extra large AD. As per documentation and explanation from VMware - Integrated Windows Authentication should work better as it use 'native searsh engine'.
Can you provide a link to me? I want to read on my own. Thanks.
BTW I didn't hear about VC will be have only one options is a VCSA. I dont know how to think about this changing right now. It is bad for us because of have pretty homo-gene infrastructure based on Windows. So it have to migrate all our stuff or recreated VC settings from the scratch. Nevertheless it is a fallback discussion of issues I have.
Hi!
Can you attach vmware-sts-idmd.log and vmware-identity-sts.log? Maybe you missed something reading the logs.
I see in vmware-identity-sts.log that 'NT Authority' returns when SSO gets information about groups membership
See timestamp 2018-01-17T10:55:32
2018-01-17T10:55:32.842+07:00 tomcat-http--5 vsphere.local
fbd4d2f6-86a6-4ebb-887f-5e0365d2d2a8 TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://rsa.com/schemas/attr-names/2009/01/GroupIdentity, format=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Groups, value=
with some other groups I see 'NT AUTHORITY\LogonSessionId_0_6878934' this is what SSO can't resolve.
Do you have any child domain or anything strange with groups for AD users?
As a test can you deploy a new VC and check how it will work with your AD.
There is also some information about compatiblity between domain levels and VC VMware Knowledge Base
Thanks for your digging up.
Yeah, I've seen that too.
I frankly don't have a clue where is VC getting this 'NT AUTHORITY\LogonSessionId_0_6878934'
The answer to your AD question is no. We have single forest, single domain - no child or sub-domains.
I've look into similar problem - https://vsential.com/2013/11/18/sso-issue-using-windows-server-2012-ad-identity-source
Unfortunately disabling this GPO setting didn't trick for me.
Before we had upgraded our DC from 2008 to 2016 Windows server OS VC is works just fine.
Can you do a simple test - creat a new user with only one group assigned like Domain Users, give it some permissions on VC and try to log in.
As well deploying a new clean VC can help to figure out it's a VC issue or it's a domain issue.
I've used your advice and accomplish this testing: created a totally new user in AD with only default "Domain Users". I've given to this test user admin permissions to entire vcenter via Global permission - no luck. I've got same client not auth error (
So the issue is not with AD groups. Any ideas?
Is there anything similar to 'NT AUTHORITY\LogonSessionId_0_*' in vmware-identity-sts.log for this test user?
Yeah, absolutely the same log's entries.
NT AUTHORITY\LogonSessionId in vmware-identity-sts.log
2018-01-19T18:06:40.766+07:00 tomcat-http--33 vsphere.local 88d61fa1-998d-4caf-bb9a-5316e5383ac4 DEBUG com.vmware.identity.saml.impl.AuthnOnlyTokenValidator] Principal {Name: vctest, Domain: domain.local}is active
[2018-01-19T18:06:40.766+07:00 tomcat-http--33 vsphere.local 88d61fa1-998d-4caf-bb9a-5316e5383ac4 DEBUG com.vmware.identity.saml.impl.AuthnOnlyTokenValidator] Token validated
[2018-01-19T18:06:40.766+07:00 tomcat-http--33 vsphere.local 88d61fa1-998d-4caf-bb9a-5316e5383ac4 DEBUG com.vmware.identity.saml.impl.AuthnOnlyTokenValidator] Token is from external idp: [false]
[2018-01-19T18:06:40.766+07:00 tomcat-http--33 vsphere.local 88d61fa1-998d-4caf-bb9a-5316e5383ac4 INFO com.vmware.identity.saml.impl.AuthnOnlyTokenValidator] Token _3945b840-fb78-478c-bd63-e3de5e91d949 for principal {Name: vctest, Domain: domain.local} successfully validated.
[2018-01-19T18:06:40.826+07:00 tomcat-http--33 vsphere.local 88d61fa1-998d-4caf-bb9a-5316e5383ac4 TRACE com.vmware.identity.saml.idm.IdmPrincipalAttributesExtractor] An attribute PrincipalAttribute [name=http://rsa.com/schemas/attr-names/2009/01/GroupIdentity, formatformat=urn:oasis:names:tc:SAML:2.0:attrname-format:uri, friendly name=Groups, value=[domain.local\Пользователи домена, NT AUTHORITY\LogonSessionId_0_290563188, vsphere.local\Everyone]] retrieved for {Name: vctest, Domain: domain.local}
To be honest, I doubt that this is a VC issue. To isolate the cause I would deploy a new test VC, join it to AD and check login.
There is another thread here in community where user wrote a workaround - create Identity Source - AD as a LDAP server this sould help.
The only thing is changed - DC have migrated from windows server 2008r2 to 2016.
AD users are able to login on vsphere client without any issues. So it is smth wrong with VC or out version of VC isn't compatible with DC
vsphere client works directly with vcenter service (vpxd). Login process using vsphere client is different when you use web client as it works with Inventory service to get information from vcenter service (vpxd).
It will take no more than 20 minutes to deploy a clean VC It's better to check as there are no other ideas
try this
Thanks for proposing a option but in KB you've provided assuming resolution for a different error. Despite that I've already tried to recreate Identity source - no luck(
Yeah... but if it will work how is helps me to figure out whats wrong with VC in the production? I dont want to migrate from one VC to another. It is works fine the only issue is auth via web and it happen just since DC have been upgraded.
So it could be MS DC AD issue as I have found https://vsential.com/2013/11/18/sso-issue-using-windows-server-2012-ad-identity-source
but this exactly solution didnt work for me
The article describes another issue with similar sympthoms.
It's up to you to test or not to test with a clean VC. However according to the steps you already tried - there is nothing to do at the moment with VC.
You can try to apply a workaround and readd Identity source with your AD as a LDAP server.
Could the newer version of VC help? I checked 6.5 have released already.
The errors showed at logs quite obvious. But how to fix it ?
As I wrote what I see that you can only do further tests - one of them installing a separate new VC. You don't need connect ESXi hosts to it. Just install and join it to AD.6.0 or 6.5 doesn't matter.
You didn't asnwer - did you try to configure identity source as a LDAP server? does it help?
I've successfully accomplished with clean reinstall new VC. 6.5U1
I've created a new datastore, cluster. test host and so on. then added an AD as identity source. As result I've successfully login on VC via Web client as well as new html5 - it is work just fine.
So it is looks like not a AD related issue, but an inventory service issue or VC 6.0 in common. Could it be added some support of new OS (Window server 2016) on 6.5 of VC release?
Ldap on the existing VC server I will try it later.
Cool. I haven't seen anything similar in release notes for VC 6.5 and all related builds.
However initially I recommended to test a fresh VC with same version and build number
Several questions:
- did you install VC 6.5 on windows machine or as appliance?
- is VC's computer account in the same organization unit in AD or in different? I mean do they have identical Group policy applied?
Another idea is to check local policy applied to production VC. Maybe something configured on this level.