VMware Horizon Community
TBC-Gareth
Contributor
Contributor

Azure MFA SSO + Horizon client login

Hi

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?

Thanks

    

 

Reply
0 Kudos
11 Replies
Mickeybyte
Hot Shot
Hot Shot

Hi @TBC-Gareth 

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. 

 

 


Regards,
Mickeybyte (ITPro blog)

If you found this comment useful or an answer to your question, please mark as 'Solved' and/or click the 'Kudos' button, please ask follow-up questions if you have any.
TBC-Gareth
Contributor
Contributor

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.    

smut5203
Contributor
Contributor

Good to hear its fixed, Thanks for sharing.

Reply
0 Kudos
5teelman
Contributor
Contributor

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?

 

Reply
0 Kudos
Mickeybyte
Hot Shot
Hot Shot

Hi @5teelman 

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.

 


Regards,
Mickeybyte (ITPro blog)

If you found this comment useful or an answer to your question, please mark as 'Solved' and/or click the 'Kudos' button, please ask follow-up questions if you have any.
Reply
0 Kudos
5teelman
Contributor
Contributor

Thanks @Mickeybyte 

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:

5teelman_1-1665473617743.png

 

5teelman_0-1665473527315.png

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.

Reply
0 Kudos
5teelman
Contributor
Contributor

Sorry for doblepost due to erroneously "spam posting" message from the website 😂

Reply
0 Kudos
Mickeybyte
Hot Shot
Hot Shot

@5teelman 

This is definitely very strange. The best thing indeed is to open a support case for this.

 


Regards,
Mickeybyte (ITPro blog)

If you found this comment useful or an answer to your question, please mark as 'Solved' and/or click the 'Kudos' button, please ask follow-up questions if you have any.
Reply
0 Kudos
5teelman
Contributor
Contributor

OK, so we figured out what was the issue - the BigIP in front of the UAG.

We did an upgrade from 15.1.5.1 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.

WouterKeus
Contributor
Contributor

Did you manage to autoclose the webpage ?

Reply
0 Kudos
5teelman
Contributor
Contributor

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 😉

Reply
0 Kudos