Horizon UAG SAMLSSO

[edennyvm]

Overnight, and without making changes, TFA for Horizon stopped working.  It goes through the authentication process (Duo) but when the browser tries to redirect to https://<oururl>/portal/samlsso it says page cannot be reached.  This is happening with the Horizon client, web client as well as with our folks using thin clients.  Horizon client logs indicate a SAML error (Your client was not launched with valid SAML2 credentials. Please contact your Administrator).  If I disable SAML auth on the UAG everything works.  Anyone seen this issue before? 

[vRickE]

Export a log bundle from the UAG and look at the log called esmanager.log look for entries related to samlsso.

It might give you the UAG side of the story.

I am too dealing with some issues with Dell Thin OS, but mine started after upgrading to UAG 2312 and using the ThinOS 2405 with client 2312 SDK version which is what they say to use now. If I roll back to the client non-SDK version, it works fine.

But checking the thin OS logs I see the same event you are seeing, and the users get an error You are not Entitled to use the system!

[Sean Massey-1]

Have you opened a ticket with support?

[edennyvm]

A support ticket has been opened.
Did find something interesting....  The IP assigned to the UAG and the IP showing in the admin console are different.  I can access the console with the assigned IP.  When I try and change the IP it says saving and does nothing.

[edennyvm]

Got it working.  It was a combo of setting the correct time zone on the UAG and I had to re-import the TLS cert and Identity Provider metadata .  We did not make any changes on our end so Duo must had did something to mess with our UAG.

[edennyvm]

Well the issue came back.  VMware support is saying that it is a clock skew issue between the UAG and Duo.

07/07 15:52:39,585+0000[nioEventLoopGroup-10-2]ERROR interceptor.ViewPortalProxyRequestInterceptor[doSamlSso: 255][107.77.208.216][][][f87b-***-67fe-***-7920-***-47ea]: UAGE00265: Error on performing SAML validation: SAML Assertion is valid between NotBefore: 2024-07-07T15:53:37Z[UTC] and NotOnOrAfter: 2024-07-07T15:59:07Z[UTC]. Please check following 1. UAG and Identity Provider time is in sync 2. SAML assertion validity set in Identity Provider is enough to account for clock skew.

I changed the time zone on the UAG and everything worked for a few days then started acting up again.  I have a ticket open with Duo.

 

And now 2 hours later it is randomly working again.  What a weird issue.

Edited July 15 by edennyvm

[Daniel Keer]

For the SAML what IdP are you using?

I have a UAG setup with Entra ID SAML and Entra is setup to use Duo and I've had no issues.

Edited July 16 by Daniel Keer

[hermanc@imsweb.com]

I ran into the exact same clock skew issue when integrating with ADFS; even though the UAGs, Horizon, ADFS are all synced with our NTP servers. 

I ended up changing the 'NotBeforeSkew' value to '1' on the relying party in ADFS and I never had the issue since. 

[edennyvm]

I ended up building a new UAG from scratch.  The UAG that was having issues magically started working again, on its own, but I didn't trust it.  Built a new UAG, needed to upgrade anyways, without importing the settings from the old one.  So far everything seems to be working as it should. 

Chad Herman - Thanks for the info.  If this issues creeps up again, I will have to look at those values you mentioned.   

Edited July 17 by edennyvm