Horizon 8 Admin Console - Login Error

[Alex Karibov]

After upgrading Horizon 8 from 2206 to any versions above (tried upgrading to 2212 and 2312) I've faced a problem with being unable to log in to Horizon Admin Console with an error "Login error. Please refresh the browser to reload the page and try again." Domain name field is NOT empty. User's authentification via Horizon Client or HTML5 works without any problems.

Tried different browsers (Chrome, Firefox, Edge) - the same error. Tried login by localhost from the server or by fqdn from my office machine - the same error.

In the debug log of CS there're some errors when I'm trying to log in:

• [TokenService] Could not retrieve current private key from certs. com.vmware.vdi.logger.Logger.error(Logger.java:92)
• [ExceptionHandlerAdvice] Unable to generate Token due to some internal error.

 

debug log.txt

[Dominik]

Did you @Alex Karibov change a certificate on connection server?

[Alex Karibov]

The certificate was changed about a year ago and is still valid. So, I didn't issue the new one for the upgraded CS.

[Dominik]

In my opinion, you have to regenerated a certificate. 

[Victor León]

Hello, 

You might be facing this issue, please check. https://kb.omnissa.com/s/article/94217

 

 

[Alex Karibov]

3 hours ago, Dominik said:

In my opinion, you have to regenerated a certificate. 

Tried to renew the vdm cert. It didn't help.

[Alex Karibov]

2 hours ago, Victor León said:

Hello, 

You might be facing this issue, please check. https://kb.omnissa.com/s/article/94217

 

 

I've checked it, but I don't have the cs-disableKeyDerivation entry at all.

Edited September 10 by Alex Karibov

[Sean Massey-1]

First, have you rebooted the impacted connection server?  You shouldn't have to do this, but sometimes it can clear up issues.

Second, have you opened a ticket with support? 

[Victor León]

Hello  

Try this as it might help. 

1. Stop the services in your CSs. 
2. Go to the location "<INSTALLDIR>\VMware\VMware View\Server\broker\webapps" in all non-working CS.
3. Delete the rest folder.
4. Restart the connection server.

Refer to: https://docs.vmware.com/en/Management-Packs-for-vRealize-Operations-Manager/1.2.1/Horizon/GUID-670DC88E-4509-416C-8CD3-AB488C1423D0.html

[Sean Massey-1]

39 minutes ago, Victor León said:

Hello  

Try this as it might help. 

1. Stop the services in your CSs. 
2. Go to the location "<INSTALLDIR>\VMware\VMware View\Server\broker\webapps" in all non-working CS.
3. Delete the rest folder.
4. Restart the connection server.

Refer to: https://docs.vmware.com/en/Management-Packs-for-vRealize-Operations-Manager/1.2.1/Horizon/GUID-670DC88E-4509-416C-8CD3-AB488C1423D0.html

@Alex Karibov - before doing the above, I'd recommend reading the linked article and doing the steps to verify the REST API in step 1 of the solution to see if you're getting this issue.  You don't want to just start deleting things on an active server if you're not sure if it's an issue.

Quote

1. Verify the Horizon Rest API access using the following steps:
   1. Enter https://{Horizon-Connection-Server-URL}/rest/swagger-ui.html URL.
   2. Click Auth Section.
   3. Click POST /login API.
   4. Click Try It Out.
   5. Replace AD-TEST-DOMAIN with the domain name, <password> with Password, and Administrator with the actual values providing to the adapter.
   6. Click Execute.

      { "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJ1c2VyLXNpZCI6IlMtMS01LTIxLT...............", "refresh_token": "eyJhbGciOiJSUzI1NiJ9.eyJ1c2VyLXNpZCI6IlMtMS01LTIxLTM0MDkw............" }

 

[Alex Karibov]

Hm, even on my 2206 where admin console works, there's an error while connecting via rest.

Then I deleted 

"<INSTALLDIR>\VMware\VMware View\Server\broker\webapps\rest"

and restart CS but nothing changed, the same 500 error.

Edited September 11 by Alex Karibov

[Sean Massey-1]

How many connection servers do you have in your environment @Alex Karibov?

[Alex Karibov]

We have 3 different installations for 3 different domains:

1. Standalone CS
   Upgrade path: 7.13.0 --> 7.13.1 --> 2206 --> unable to upgrade futher due to the problem
2. Paired CS (Standard + Replica)
   Upgrade path: 7.11 --> 7.13.1 --> 2206 --> unable to upgrade futher due to the problem
3. Standalone CS
   Upgrade path: 2209 --> 2212 --> 2312.1

So, there's the problem with only 1 and 2 installations which were fresh installed with Horizon 7 CS and then upgraded to Horizon 8, but not with 3 one which was fresh installed with Horizon 8 CS.

[Cliff]

Im fairly certain this issue is resolved with 2406

[Sean Massey-1]

10 hours ago, Alex Karibov said:

We have 3 different installations for 3 different domains:

1. Standalone CS
   Upgrade path: 7.13.0 --> 7.13.1 --> 2206 --> unable to upgrade futher due to the problem
2. Paired CS (Standard + Replica)
   Upgrade path: 7.11 --> 7.13.1 --> 2206 --> unable to upgrade futher due to the problem
3. Standalone CS
   Upgrade path: 2209 --> 2212 --> 2312.1

So, there's the problem with only 1 and 2 installations which were fresh installed with Horizon 7 CS and then upgraded to Horizon 8, but not with 3 one which was fresh installed with Horizon 8 CS.

First, I would strongly recommend opening a support ticket for this issue.  If you have two environments that were upgraded from 7.x to 8.x/2206, there might be an internal KB that describes this issue and how to resolve it.  Or you can get advice to proceed with upgrading to a release that fixes this issue.  But you would need an official answer from support on this.

Second...I would STRONGLY recommend installing a 2nd CS in each of your environments to provide you with redundancy.

[Jeremy Wellner]

From what I'm seeing, the first thing that almost always needs to be checked post upgrade is the locked.properties config as each subsequent version has been increasing in security defaults that need to be properly configured and not just turning them off.

Please see this KB for reference - https://kb.omnissa.com/s/article/94578?lang=en_US

The other thing I'm seeing in your log snippet is that the private key for your cert may not be exportable.

Please see this KB for reference to verify - https://kb.omnissa.com/s/article/80303?lang=en_US

Edited September 12 by Jeremy Wellner

[Alex Karibov]

On 9/12/2024 at 6:49 PM, Sean Massey-1 said:

First, I would strongly recommend opening a support ticket for this issue.  If you have two environments that were upgraded from 7.x to 8.x/2206, there might be an internal KB that describes this issue and how to resolve it.  Or you can get advice to proceed with upgrading to a release that fixes this issue.  But you would need an official answer from support on this.

Second...I would STRONGLY recommend installing a 2nd CS in each of your environments to provide you with redundancy.

Unfortunately, I'm unable to open a support ticket now because our contract has been suspended due to some political reasons. If I had a chance, I'd definetely done it first.
The same obstacle with upgrading to 2406 cause it requires to upgrade the license on the Omnissa portal.

Futhemore, I've tried to look through all of the release notes for all the versions of Horizon and couldn't find anything about REST API in resolved issues.

[Owen Ye]

On 9/10/2024 at 10:40 PM, Alex Karibov said:

I've checked it, but I don't have the cs-disableKeyDerivation entry at all.

would you please try adding cs-disableKeyDerivation=0 and restart service.

[Alex Karibov]

On 9/23/2024 at 4:48 AM, Owen Ye said:

would you please try adding cs-disableKeyDerivation=0 and restart service.

Tried to add this, restarted the wsbroker service but nothing changed, the same error 500 when logging to rest api.

[robryan]

Your problem is with locked.properties - literally just ran into this same problem upgrading my lab a couple weeks ago, kb article also proved equally as useless due to that setting not even existing in the ADAM database.

There are a number of security options in there that are now on by default that can block various connection scenarios and unfortunately don't necessarily provide the most informative feedback about what's preventing what. 

Now, I needed my lab to be functional to work a customer problem, so I took a shortcut and just added this to the top of my locked.properties file and restarted:

allowUnexpectedHost=true
checkOrigin=false
enableCORS=false

.. but I would not necessarily recommend running long term in production with that because bypassing security functions isn't necessarily the greatest idea, and I'd love to tell you exactly which one was what ultimately let me back into the admin console, but I can't seem to break it again by backing those out to put in a proper configuration 😄

I will reiterate Sean's point above about installing 2nd Connection Servers in each environment though, think of these like Domain Controllers - if something goes awry on one, it can kill everything so it's always good to have n+1 redundancy at a minimum.