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

[maxim315]

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?

[maxim315]

Please find below the answers on your questions

- I've installed a new 6.5 VC on Windows 2016 OS VM

- From the start I've put the new VC's computer object into test OU (some GPO setting wont applied as for productive VC), but according to your comment I've moved 6.5 VC to the same OU as 6.0 VC then reboot the VM. AD login into web client work just fine. So it look like smth broken on 6.0 VC after DC were changed.

I will try to use ldap auth to test on productive VC

[maxim315]

Okaaay.

I 've configured AD identity source as LDAP and it is work. AD user successfull login via web client as well as windows vsphere client. Kinda weird, why is integrated win auth could be broken for inventory service?

Although there are a lot of errors like this:

vmware-sts-idmd.log

[2018-02-01T12:26:42.388+07:00 vsphere.local        40bbf1de-0eed-4e84-9d29-4a8e2218df9b INFO ] [IdentityManager] Failed to find group [some AD group@domain.local] as FSP group in tenant [vsphere.local]

Is there a need to reduce an DN search zone to some specific OUs as it full Domain for now?

[Finikiez]

I would ignore such errors as SSO tries to check all identity sources for related groups. And obviously domain groups don't exist in SSO domain.

Some more ideas:

- install latest Windows patches on production VC (make a snapshot before installing anything)

- check SSO logs on production VC for any similar to 'NetLogon...' when identity source is configured as LDAP

- check SSO logs on test VC for the same

- see if the issue exist if install test VC with exactly the same build number

If you don't any special requirements I would recommend to use the whole AD as base DN for groups and users.

[maxim315]

I've checked for 'NetLogon...' at vmware-sts-idmd.logs - just nothing for both of VC's (test and production).

Last time Windows patched were installed few month ago, about a Oct 2017 I suppose. It is not too long enough.

I have a thought: could it be that production VC's keep into some of it SQL DB table the old guid for DC or some wrong value? I ran into a such thing that reset inventory database could help in that case, but this operation is quite destructive and complex. What do you thing?

At least LDAP options is works fine for now. I think there are no such difference in between integrated AD auth or LDAP, am I right? I suppose we can stop on LDAP configuration for now if nothing are help me out to make windows integrated feature work back again. So we should migrate to a newer version of VC (6.5 or 7.0) in for e.g. a end of a year.

[Finikiez]

I have a thought: could it be that production VC's keep into some of it SQL DB table the old guid for DC or some wrong value? I ran into a such thing that reset inventory database could help in that case, but this operation is quite destructive and complex. What do you thing?

I doubt that this is related to inventory service. As Inventory service is a man in the middle between web client and vpxd. And you have the issue with SSO.

Resetting IS database is mostly disruptive when you have external solutions like vCloud Directory.

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

If you are ok with this identity source configuration it's fine.

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

Also keep in mind, that 6.5 is the last release where VC on windows exists.

Consider to move to VCSA in future.

You can convert VC on windows to VCSA during upgrade from 6.0 to 6.5. Overall process Step-by-step: Migrate Windows vCenter server to vCSA 6.5u1 -

It's not possible to convert windows VC to VCSA within the same version like windows VC 6.5 to VCSA 6.5

[maxim315 · Accepted solution]

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.

[13thDisciple]

if they migrated to a new servers, is it possible you may have trusts or certificates that need to be re-established?

[Finikiez]

there is no such 'AD' provider. List of providers is in KB as well. You can try to reset 'vpx' provider. It's not disruptive.

However take snapshot\backup before doing this.

Strange, I can't find this link now. The other difference is that you don't need to join your VC to AD to user identity source type 'AD as a LDAP server'

Here is the link with anouncement of deprecation VC on Windows Farewell, vCenter Server for Windows - VMware vSphere Blog

The same thing will happen with the Web client as well Goodbye, vSphere Web Client! - VMware vSphere Blog

[maxim315]

if they migrated to a new servers, is it possible you may have trusts or certificates that need to be re-established?

nope. AD DCs were migrated to a new servers - 2016 not the VC. there were nothing we did on VC side. AD was configures as integrated source not ldap, so there are no certification trust.

I've installed a new VC 6.5 for a testing purpose only.

[maxim315]

Many thanks to you for info you've provided.

I will think about it. However I dont see any

All errors I've seen before related to invsvc service, not vpx. So I have a doubt that resetting vpx provider could be helpful.

BTW is VC snapshot be helpful in case something wrong with resetting?

[Finikiez]

VC snapshot can help to roll back quickly.

Also if you have external PSC and external DB than make a snapshot from PSC and DB backup as well.

This will allow you to restore all if something goes wrong.

[maxim315]

Nope, I can DB on the same VM along with VC.

Ok, thanks. I have a thought VC could make somt disruptive changes on ESXi hosts in case if smth goes wrong. I will try.

So what about vpx reset, you didnt comment this part

[Finikiez]

I wrote that from my perspective resetting any IS provider can't help. Because IS doesn't take a part in login process into web client. However when you run out of ideas it's a time to check everything you can check )

Resetting IS providers help only if you have issues with displaying information in Web Client when you are already loged in.

Resetting vpx provider is not disruptive for ESXi hosts at all.