We have setup Azure MFA for Unified Access Gateway authentication and all working fine. The only issue we have is that once authenticated through Azure i.e. after the user is redirected to the Azure logon to enter their UPN/password and MFA details, the Horizon Client then loads but also requires network credentials again from the user. Ideally we wanted to remove this given the user has already authenticated once. We've looked at TRUESSO and set it up in a test environment but that doesn't seem remove the requirement to sign into the Horizon client. Also tried the 'login as current user' setting in the client, that also doesn't work and the user is still required to login to the Horizon client.
Any suggestions how we remove the requirement to login into the Horizon client after successfully authenticating through Azure MFA?
Check my blog posts on VMware Horizon authentication using AzureAD (with multifactor) – MickeyByte IT Pro Blog.
I think the SAML part (VMware Horizon authentication using AzureAD (with multifactor) – Part 4: SAML Setup – MickeyByte IT ...) will be the one you need to double-check to see if everything is setup correctly.
Thanks for that @Mickeybyte ,guides really useful. Checked the SAML setup and I had the auth method in the UAG Horizon settings set to SAML and Passthrough rather than just SAML. Now only requires the Azure credentials.
Great writeup @Mickeybyte - thanks for sharing! We have identical setup, Horizon 8.6, UAG 2207 with Azure SAML and TrueSSO like this, works perfectly with the HTML client. We do though have some challenges getting a native client initiated session to come back to the native client after authentication, it stays at the /portal/webclient page.
I can't find anywhere that someone actually has shown that working or what needs to be changed in the config, besides in this video: https://www.youtube.com/watch?v=asLT1aHrBvM (which is with Okta, though SAML, hence same-same ...)
In your setup, does it redirect back to a native client session after authentication and MFA?
Yes, after logon to Azure, the native client pops up again showing the available pools for that user. However, the webpage used for the sign-on doesn't closes itself, so it stays in the back.
But in our case the native client tells me this in it's log when I try to connect (authentication in Azure with MFA done successfully):
2022-10-10T13:04:58.726+02:00 EROR (01) [libsdk] : Cdk::ErrorCallback:866: The task 'CdkGetConfigurationTask' failed with error: Your client was not launched with valid SAML2 credentials. Please contact your Administrator. (domain=55, code=3).
2022-10-10T13:04:58.752+02:00 EROR (01) [libsdk] : ServerErrorHandler::OnError:71: Handling error 'Your client was not launched with valid SAML2 credentials. Please contact your Administrator.' (domain=55(CDK_BROKER_ERROR), code=3) from task CdkGetConfigurationTask.
2022-10-10T13:04:58.752+02:00 INFO (01) [libsdk] : Server::HandoffToWorkspaceOne:1628: (26474C6C0D0) The server is in Workspace ONE mode: uag.corp.com/portal/nativeclient
2022-10-10T13:04:58.752+02:00 INFO (01) [ServerService] Handoff:1131 Handing off to https://uag.corp.com/portal/nativeclient
2022-10-10T13:04:59.146+02:00 INFO (01) [ServerService] Shutdown:213 The client is forcibly shutting down, clear all pending actions...
2022-10-10T13:04:59.147+02:00 INFO (01) [ServerService] Shutdown:228 The server https://uag.corp.com/ has no session. Will quit after logged out.
2022-10-10T13:04:59.147+02:00 INFO (01) [client] Disconnect:1205 The server https://uag.corp.com/ is disconnecting...
But the CS isn't:
If I continue with the HTML portal, the VDI opens without further authentication, hence SAML and TrueSSO works.
As we're on the latest versions of all components (client, uag, Horizon CS), and all configs are done "by the book", I guess this will end as a ticket with support. I really cannot see anything that should lead the client and/or CS to see this as Workspace ONE mode.
This is definitely very strange. The best thing indeed is to open a support case for this.
OK, so we figured out what was the issue - the BigIP in front of the UAG.
We did an upgrade from 184.108.40.206 to 15.1.7 and recreated the profiles there from the iApp f5.vmware_view.v1.5.9 package, and ta-daa - it worked. No other changes on UAG or CS, hence something in the old (working with Horizon7) config fooled us here ...
The only "nag" now is the browser window that's not closing, but it should be possible to autoclose with some scripting if needed.
We haven't done anything about it yet, hence the users just close it themselves - or reuses the browser for something else anyway. It should though be some "autoclose timer feature" in the webservice made available as an option by VMware in the config 😉