VMware Horizon Community
jksnbco
Enthusiast
Enthusiast

Horizon Client - Access Denied after implementing MFA on UAG

We recently implemented MFA in UAG via SAML authentication with Azure AD.

 

We have two UAG3.8 servers set up.  We are using round robin DNS. 

 

Randomly, we get an 'access denied' error from the horizon client when trying to connect remotely. 

 

'Access denied' Steps

1. Launch VMware horizon Client

connection 1.PNG

2. Login with credentials in client.

3. Web browser opens, prompting to open VMware Horizon 32 bit client.  User clicks open. 

 

4. Access denied error occurs

access denied horizon client.PNG

 

We have tried connecting to each UAG to see if one UAG is having an issue, but the behavior randomly occurs on each UAG. 

 

When it works, step 4 does not occur.  The user is prompted again for credentials, then presented with their desktop options.  the problem has not occurred prior to implementing MFA. 

 

Issue has occurred don Horizon client 5.4.2 and 5.4.3

VMware horizon view version 7.11

 

An SR has been created for this, but wanted to see if anyone else has run into this problem.

11 Replies
jksnbco
Enthusiast
Enthusiast

We have also tried setting Edge Chromium, Chrome, and Internet Explorer 11 as the default browser.  Behavior still randomly occurs. 

Reply
0 Kudos
EricMonjoin
Expert
Expert

Are you sure you don't have any issue with your load balancer between UAG and Horizon (sessions persistance) or in front of UAG ?

Did you check logs in your Connection servers ?

Reply
0 Kudos
bjohn
Enthusiast
Enthusiast

Just curious, why would get an option to open the 32-bit horizon client when you are already launching the horizon client?

Reply
0 Kudos
chsa_topsoe
Contributor
Contributor

Did someone manage to find solution?

I am in this exact same situation of random "Access Denied" by Horizon Client only. The HTML connection doesn't give this issue.

I have both UAG's at 3.10 along with Horizon 7.13. Tried with client 2006 and 2012.

What did VMware conclude in their SR?

Best regards.

Reply
0 Kudos
JasonP76
Enthusiast
Enthusiast

Hey All,

I also have the exact same issue, even with UAG 2207 and Horizon CS 2209. Can be any client 8.x version also. They all do the same thing. load up Chrome/Edge and then when authenticated and being passed back to the client it Errors with Access Denied.

This is becoming increasingly frustrating.

 

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast

In order to isolate the issue, I would recommend the following:

  1. Point UAG1 to Connection Server 1 ( Destination URL under Edge Settings)
  2. Point UAG2 to Connection server 2
  3. Then use IP address of specific UAG and check if the issue is reproducible.

DNS Round Robin is not a best solution. Client send "Set Last User Activity". If there is not session persistence the DNS RR may route to incorrect UAG or Connection server after DNS cache is timedout and will cause the issue.

 

 

Reply
0 Kudos
JasonP76
Enthusiast
Enthusiast

That is exactly how we have it set up already

UAG1 -> CS1

UAG2 -> CS2

TTL on DNS Entry is 10 minutes, so there is no chance that the TTL time out occurs during the User Sign in process. They sign in within a minute of making the connection to the UAG, after which, when they have been successful, there is never a disconnection, because on the UAG you have to set the exact DNS Entry of that UAG for the Blast External URL and the Tunnel External URL. These are passed back to the client when a successful connection is made (which is what the client uses going forward to keep the connection up). the DNS Round robin address is only used at initial point of connection/authentication.

We noticed that when we set the browsers to incognito mode the issue does not occur. Clearing browser cache before logging in also seems to help with this issue, but we can't tell users that they have to keep doing this on their PCs just to connect in. On most occasions they forget.

Also if a user signs into the HTML version of Horizon then closes that and opens the client it works.

There seems to be something with the browsers possibly holding a stale record of a previous session, and when the authentication is made and the session token is passed over to the Horizon Client, it may be sending the old stale token and not the new one, hence giving the user the Access Denied message

Reply
0 Kudos
JasonP76
Enthusiast
Enthusiast

All,

So I think I found the solution to this issue.

The issue we have really does revolve around DNS round robin and Microsoft Authenticator (Azure AD), but maybe someone can still get an idea from this.

So from a high level look what you see is this:

  1. Client opens and you initiate the connection the to the LB/DNS RR. (One set of logs is created for the client)
  2. Client forwards Authentication to the SAML Portal on the UAG, which in turn closes the client and opens a browser to this portal
  3. Once successfully authenticated the client is then reopened and the session token is passed to the client. (Another set of logs for this client)

Step 3 is where this fails. and the reasons below.

  • within the UAG you should have "Host Port Redirect Mappings" set for each individual UAG to rewrite the URL from the LB URL to the actual Site UAG URL
  • This URL rewrite is used to push to the correct SAML portal on the UAG for auth as stated in step 2
  • Within the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon you would have a default url checked. This URL should really be the same URL as your LB/DNS RR. 
  • Between step 2 and step 3 is where this fail occurs. If your TTL is set to low on your DNS RR URL then during the time from step 1 to step 3 of the browser opening the client for you, the DNS entry for your DNS RR would have timed out. Also when the client opens up for the second time it is actually forced to redirect from the exact UAG URL that you set in the "Host Port Redirect Mappings" back to the DNS RR URL that you have set as default for the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon (this can be clearly seen in the second set of logs that get created when the client opens up again). If at this point the TTL timed out on the DNS RR and it tries to resolve it will resolve the other site's IP and therefore give you the Access Denied as that is not the URL you initiated the session from.
  • So you need to increase the TTL on the DNS RR entry. We set ours to an hour and so far we have not had any users have this issue anymore

 

Hope this helps someone in the future if they come across the same problem

jpycroft
Contributor
Contributor

Hi,

We experienced the same issue randomly amongst users.  We are currently testing with new UAG's and new NLB in front of them.  The UAG tunnel urls are configured with the resolvable host name of the new UAG(s) so my understanding is that after authentication, the client is returned the UAG hostname set in the tunnel url so the secondary Blast connection should connect to the same UAG as it authenticated.  I've held off adding the host rewrite at this stage until users have tested.

Thanks,

Reply
0 Kudos
mrkasius
Hot Shot
Hot Shot

Hi @jpycroft

That's correct. The secondary Horizon protocol (Blast) must be routed to the same UAG appliance to which the primary Horizon authentication was routed.

Reply
0 Kudos
brandonp3
Contributor
Contributor

Hi @JasonP76,

This was a great explanation and a big help.  Setting the "Host Port Redirect Mappings" and extending the TTL is what solved my headaches.  Out of curiosity, with the setup you described, the VMware Horizon Client adds the UAG URL as a connection after Azure hands the auth process back to Horizon.  Do you do anything to obscure that UAG URL connection so end users only use the LB URL or do you just train them to only use the LB URL?

Thanks!

Reply
0 Kudos