VMware Horizon Community
mrstorey303
Enthusiast
Enthusiast
Jump to solution

UAG Blast Tunnelling for HTML Connections Only?

I'm working on a True SSO design for our company now that Horizon supports 3rd party IDPs (ie you're not tied into using VIDM for SAML auth anymore).

My understanding is that UAGs are a required component to handle auth, regardless of whether you're inside our outside the company network.

Right now, I've configured internal clients to resolve directly to the connection servers, and I've enabled 'Use Blast Secure Gateway for only HTML Access connections to machine'.  This allows incoming connections from thick / installable clients to connect to brokered desktops directly, providing a more efficient traffic path, while overcoming the annoying cert warnings you'd get when connecting directly with an HTML5 client (I know there are ways around this, but none are desirable - it's just easier to tunnel HTML5 connections and tell users you'd get better performance from the installable client).

So, in a True SSO world, I'll need to deploy UAGs internally and resolve users to them instead.  So my question:

Is it possible to enable selective tunnelling on UAGs, so that only HTML5 clients will tunnel, and installable clients will go direct?

Thanks,

Alex

Reply
0 Kudos
1 Solution

Accepted Solutions
EricMonjoin
Expert
Expert
Jump to solution

Alex,

Yes you need UAG (3.8 or later) for 3rd party IDP using SAML and TrueSSO associated with Horizon 7.11 and later even for internal and No, you can't enabling selective tunneling on UAG, as soon as you pass by any UAG then your connection is tunneled and all traffic will pass through it.


Eric

View solution in original post

4 Replies
Shreyskar
VMware Employee
VMware Employee
Jump to solution

Hi mrstorey303

UAG is not required for internal connections. UAG is a reverse proxy device which is ONLY required for external connections(deployed in DMZ) however you can configure it for both internal as well as external connections but that means even your internal connections have to go through an extra hop which is not required at all since internal connections are always trusted.

This answers your last question as well, since UAG's job is to direct ONLY authenticated request to internal resources, it has to tunnel the initial connection request, you can not disable tunneling on UAG. The secondary connection which is when you launch your desktop (PCoIP,blast,RDP) can be configured to by pass tunneling and make a connection directly to VDI.

Reply
0 Kudos
mrstorey303
Enthusiast
Enthusiast
Jump to solution

Sure, I'm aware of what UAGs are for - the background to my question was specifically around configuring True SSO with 3rd party IDPs (ie, an IDP other than VIDM).

It's my understanding that this feature:

- Was introduced with Horizon 7.11

- Required UAG 3.8 and above.

I don't want to deploy UAGs internally, but I'm led to believe they are 100% required in order to handle SAML auth with a 3rd party IDP (in our case, Okta), and have the resulting SAML assertion work alongside Horizon True SSO infrastructure.

Can anyone confirm or deny?  Our account team has clearly stated that UAGs are required for this type of auth (regardless of where you're authenticating from).  But, hey, it's a new feature, we may be in a minority with wanting to leverage it - people can be wrong sometimes.

Reply
0 Kudos
EricMonjoin
Expert
Expert
Jump to solution

Alex,

Yes you need UAG (3.8 or later) for 3rd party IDP using SAML and TrueSSO associated with Horizon 7.11 and later even for internal and No, you can't enabling selective tunneling on UAG, as soon as you pass by any UAG then your connection is tunneled and all traffic will pass through it.


Eric

mrstorey303
Enthusiast
Enthusiast
Jump to solution

OK thanks, this is what I figured.

In which case, I guess my options are for internal TrueSSO are:

- Enable tunnelling - both thick clients and HTML5 clients are tunnelled regardless.

- Disable tunnelling, but configure the connection servers to return a DNS name rather than IP address, so that direct HTML5 connections do not throw a cert warning.  (Not entirely happy to do this, because it'd introduce a significant dependancy on accurate DNS queries for instant clones / highly ephemeral environments.  I could see an issue where users are brokered out to different machines to what the connection server allocated!)

I should probably throw in a feature request for the UAG product team.  Just as a side, I've always wondered why these cert warnings only throw for brokered, direct HTML5 connections, and not brokered direct connections from the thick client?  Maybe a question for another thread!

Thanks

Reply
0 Kudos