maxim315
Enthusiast
Enthusiast

Client is not authenticated to VMware Inventory Service - http://localhost:10080/invsvc

Jump to solution

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?

0 Kudos
1 Solution

Accepted Solutions
maxim315
Enthusiast
Enthusiast

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.

View solution in original post

0 Kudos
32 Replies
Finikiez
Champion
Champion

Hi!

Can you attach vmware-sts-idmd.log and vmware-identity-sts.log? Maybe you missed something reading the logs.

0 Kudos
maxim315
Enthusiast
Enthusiast

Hi Finikiez

I dont think that I could miss smth important.. Nevertheless I've attached it. Hope you will find out smth usefull.

0 Kudos
Finikiez
Champion
Champion

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

maxim315
Enthusiast
Enthusiast

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.

0 Kudos
Finikiez
Champion
Champion

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.

0 Kudos
maxim315
Enthusiast
Enthusiast

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?

0 Kudos
Finikiez
Champion
Champion

Is there anything similar to 'NT AUTHORITY\LogonSessionId_0_*' in vmware-identity-sts.log for this test user?

0 Kudos
maxim315
Enthusiast
Enthusiast

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}

0 Kudos
Finikiez
Champion
Champion

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.

0 Kudos
maxim315
Enthusiast
Enthusiast

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

0 Kudos
Finikiez
Champion
Champion

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 Smiley Happy It's better to check as there are no other ideas

0 Kudos
RajeevVCP4
Expert
Expert

try this

VMware Knowledge Base

Rajeev Chauhan
VCIX-DCV6.5/VSAN/VXRAIL
Please mark help full or correct if my answer is use full for you
0 Kudos
maxim315
Enthusiast
Enthusiast

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(

0 Kudos
maxim315
Enthusiast
Enthusiast

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 Smiley Sad

0 Kudos
Finikiez
Champion
Champion

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.

0 Kudos
maxim315
Enthusiast
Enthusiast

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 ?

0 Kudos
Finikiez
Champion
Champion

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?

0 Kudos
maxim315
Enthusiast
Enthusiast

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.

0 Kudos
Finikiez
Champion
Champion

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.

0 Kudos