Between step 2 and step 3 is where this fail occurs.This URL should really be the same URL as your LB/DNS RR. Within the Reply URL section of the Enterprise application set in Microsoft Azure for Horizon you would have a default url checked.This URL rewrite is used to push to the correct SAML portal on the UAG for auth as stated in step 2.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.Once successfully authenticated the client is then reopened and the session token is passed to the client.Client forwards Authentication to the SAML Portal on the UAG, which in turn closes the client and opens a browser to this portal.(One set of logs is created for the client) Client opens and you initiate the connection the to the LB/DNS RR.So from a high level look what you see is this: 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 I think I found the solution to this issue. 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 On most occasions they forget.Īlso if a user signs into the HTML version of Horizon then closes that and opens the client it works. 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. We noticed that when we set the browsers to incognito mode the issue does not occur. the DNS Round robin address is only used at initial point of connection/authentication. ![]() 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). 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. TTL on DNS Entry is 10 minutes, so there is no chance that the TTL time out occurs during the User Sign in process. That is exactly how we have it set up already
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |