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
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
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.
We have also tried setting Edge Chromium, Chrome, and Internet Explorer 11 as the default browser. Behavior still randomly occurs.
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 ?
Just curious, why would get an option to open the 32-bit horizon client when you are already launching the horizon client?
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.
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.
In order to isolate the issue, I would recommend the following:
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.
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
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:
Step 3 is where this fails. and the reasons below.
Hope this helps someone in the future if they come across the same problem
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,
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.
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!