There might be use cases where we want to design our horizon environment in a way that we use the UAGs not just for external unsecure access, but internally as well.

Examples:

• Offering access to internal users coming from a not so trust-worthy site/location (including a second-factor authentication for those users). // Access restricted via Firewalls/ACLs
• Constraints to always use tunneled connections (because of network-simplicity or security constraints).

How would we have dealt with this situation in an older environment including a Windows based Security Server? Since the Security Server required a 1:1 pairing between a Connection & a Security Server we would easily hit the maximum number of 7 Connection Server in case that we want to offer multiple accesses from different locations.

Let’s assume the following scenario. We need to offer access to 4 types of users:

• Access from the internal head-quarters (HQ) – All virtual Desktops are hosted within the HQs datacenter.
• Access from a branch-office that must use RSA-token
• Access from a branch-office in a different not-so-well-trusted country that is only allowed to communicate with a single Endpoint within the (HQ) network
• Access from the internet for a specific User group

The following logical design would be a solution using windows based security server

Why is that architectural approach not so beneficial?

• Availability: The maximum number of Connection Server that can be used (master & replica) is 7. We are not able to fulfill the required scenarios without hitting that number and have full redundancy for specific access components
• Maintainability: All Connection Server are Windows based. If the Connections are tunneled (which is required in our scenario) we would have more user struggle when patching the Connection Servers underlay windows (Since the connection will drop). In this solution design 9 Windows Machines must be managed in a careful way to minimize user impact

How could we achieve the same functionality with the Unified Access Gateways?

What is the advantage of this design approach?

• Availability: 2 Windows Connection Servers only. Since we are not constraint by a 1:1 relationship between the UAG and the Connection Server we are much more flexible and can create full redundancy for all access ways.
• Maintainability: All tunnels between the end users Endpoint and their respective Desktop is tunneled over the UAG. The reboot and patching of the Windows based connection server can be done completely seamless for the end-user. So we don’t need to patch the hardened linux appliance? For sure we do. But the process around here is much easier. Quiesce the UAG within the respective administration interface. Existing sessions will remain, new sessions will not be created over that UAG, the load-balancer will get a different https response which will remove it out of the load-balancing. Next step: Deploy a new UAG with the newer version, import the configuration file, add it to the load balancer application pool and voila. That’s it!!!!
• Security: The UAG is a hardened Linux appliance. I hated the discussions with the infosec guys in the past about placing a Windows Server in the DMZ.

Remember that you can tag the UAG as an internal or external access component. If it is configured as external you can use the restriction functionality within Horizon (e.g. only specific member of an AD-Group can access Desktops over the Internet or User Environment Manager (different in-guest security policies based on the access components).

I know those are very extreme /rare examples, but the key message should be clear. Using those stateless Unified Access Gateways gives us much much more flexibility in how to design and operate the virtual Desktop and Application access layer.

Original Post: https://vlenzker.net/2018/04/using-vmwares-unified-access-gateway-uag-for-internal-horizon-7-connections-design-discussion/

‍