Wednesday, July 5, 2023

A Primer On Unified Access Gateway For Citrix Admins Migrating To VMware Horizon

Folks considering a migration from Citrix to Horizon naturally ask, "what's the Horizon equivalent of NetScaler?"  Though Unified Access Gateway (UAG) is the closest comparison, it's not a single like-for-like equivalent to NetScaler.  NetScaler is a multi-purpose application delivery controller, traditionally sold in pairs of physical appliances, with a history of solving complex problems far beyond the scope of Citrix remoting.  In contrast, Horizon's UAG is a purpose built, exclusively software based technology dedicated to VMware EUC workloads and little else.  So, while both solutions are used to proxy display protocol traffic for their respective suites, they're very different in scope and approach.  That said, to compete with the broader set of NetScaler capabilities UAG combines with components across the entire VMware portfolio to provide a modular, elastic, and cost effective alternative.

To be clear, NetScaler is very impressive tech with a broad set of capabilities extending far beyond app and windows remoting.  Load balancing, GSLB, web security, TCP offloading, etc... The common refrain is, "NetScaler does everything." The problem is NetScaler does everything and is priced accordingly, despite the fact most Citrix customers need it simply to proxy ICA sessions.  Usually these organizations have some other load balancing or ADC solution in place and quite often you hear of NetScalers sitting in the same racks as F5 appliances.  Unfortunately, NetScalers dedicated exclusively to the proxying of ICA sessions is an extremely common scenario, overkill most Citrix customers find themselves forced into as soon as remote access is required.  A colleague of mine jokes it's like having a Ferrari to drive 35mph for three blocks to a local market once a week.  In stark contrast stands Unified Access Gateway, a standard component of all VMware EUC suites, deployed at no additional cost, save the modest vSphere capacity used to run it.  While it already had proven itself by 2019, it's stellar performance during the pandemic cemented it's status as a hardened and mature solution.  At a time when supply chains were gummed up and procuring new devices was a real challenge, software based UAG appliances came to the rescue, enabling Horizon customers to address spikes in remote work using spare vSphere capacity they had lying around. 

UAG was initially released about 8 years ago, with tens of thousands of instances deployed world wide today.  Most customers have met their Horizon remote access requirements using UAG alone or UAG coupled with Workspace ONE Access, VMware's identity-as-a-service offering.  However, organizations looking to sever ties with Citrix entirely may have a broader set of NetScaler capabilities to consider, beyond windows/app remoting or the EUC space entirely. To reiterate, the Horizon suite doesn't include a single product that competes directly with NetScaler.  However, the foundational functionality of UAG combined with the rest of the VMware portfolio overlaps a great deal with what most Citrix customers are doing with NetScaler today.  Though this combined offering doesn't cover absolutely everything NetScaler does, it certainly covers what's most common and germane, while introducing modern software and SaaS based alternatives.  Moreover, for a refreshing change, Citrix customers migrating to Horizon can freely and without coercion pick and choose amongst an al a carte alternative according to their specific needs. 


Customers using NetScaler to simply proxy published applications and VDI can likely meet their Horizon remote access requirements using UAG and whatever load balancing solutions they already have deployed.  If they're leveraging advanced authentication capabilities of NetScaler for Citrix sessions, for Horizon they can leverage UAG's built-in support for stronger forms of auth or tap into the capabilities of Workspace ONE Access.  In the case of Citrix customers using NetScaler for load balancing enterprise wide, VMware's Advanced Network Load Balancer (Avi) is a compelling software based alternative to consider.   For those leveraging the VPN capabilities of NetScaler, UAG and Workspace ONE UEM combine to deliver a Per-App VPN alternative.   Heck, for certain NetScaler use cases some customers might find VMware's SD-WAN offering, based on VeloCloud, a better fit.  The bottom line is that money spent on NetScaler could purchase an awful lot of different VMware products al a carte.  Further, if there isn't commitment to a one throat to choke model, shoot, VMware has plenty of partners to choose from.  Big picture, there's the question of what you can get done with the included remote access capabilities of the Horizon suite plus whatever solutions you could procure with resources previously dedicated to NetScalers.  That's a lot to think about.

Regardless of what NetScaler functionality might need replacing, UAG is definitely in the future of any Citrix admin migrating to Horizon.  Accordingly, this post provides a concise primer on UAG while calling out key differences between UAG and NetScaler when it comes to remoting.   First and foremost, UAG adoption represents a shift to an infrastructure as code strategy for delivering remote access.  This model is dependent on some sort of external load balancing, whether it be a 3rd party solution or VMware's own NSX Advanced Network Load Balancer (Avi).   After detailing this requirement, UAG options for stronger forms of authentication will be reviewed, both it's built-in capabilities and those gained from Workspace ONE Access, a SaaS solution included with Horizon Universal licensing.  Along with providing a catalog experience similar to Store Front, WS1 Access acts as an IDP, wrapping modern auth around Horizon and enforcing authentication requirements through a context aware policy engine.   Both NSX Advanced Load Balancer and WS1 Access are excellent examples of VMware's ability to replace NetScaler functionality with modular and elastics solutions.  Reviewing their adoption will shore up the readers understanding of UAG while providing context for other migration options from NetScaler to VMware solutions and services.  In a final twist, I'll call out a very reasonable path forward, using NetScaler and UAG together.  If not a permanent architecture, leveraging NetScaler + UAG is a very viable and in some cases, ideal solution, allowing folks to realize value in their NetScaler investments while they focus on the migration of app publishing and VDI to Horizon. 


Infrastructure As Code 

UAG was first released 8 years ago as an alternative to the Windows based Horizon proxy solution called Horizon Security Server.  As opposed to it predecessor, UAG is a hardened linux virtual appliance currently based on photon OS 3.0.  It's typically deployed on top of vSphere, though it's also deployed natively to clouds like AWS, Azure and GCP.   Over the years it's role has expanded to accommodate Workspace ONE UEM solutions like Per-App VPN and SEG.  Throughout the course of it's development security and stability have been a top priority, a fact quickly evident to anyone who's worked with the product.   Quite frankly, these things don't really break.  Most of the troubleshooting happens during initial setup and easily 95% of the time problems are with external environmental factors like misconfigured firewalls or general networking challenges.   Once UAGs are setup properly they just work and don't require much in the way of care, feeding, or maintenance.  With the release of Horizon 8 in 2020 UAG became the primary mechanism for supporting remote Horizon access as Security Server was deprecated.  By then, there was already tens of thousands of successfully deployed UAG instances, along with a rich set of documentation and codified best practices.  In short, UAG is boring, reliable, proven and predictable plumbing used by VMware's EUC solutions to provide secure access to on-premises resources.   

While security and reliability were top developmental objectives for UAG, ease of deployment was certainly lower down on the list of priorities.  Typically, mature environments entail the deployment of UAGs through PoweShell scripts run against vSphere.   This can be initially off-putting for folks, given network infrastructure specialist normally don't get their hands dirty with scripting.  However, while you're running a pre-canned PowerShell script provided by VMware, you're not actually writing or tweaking out PowerShell.  You're focus is on tweaking out an ini config file that the PowerShell script is run against, populating the ini file with info about your UAG instance like ip addresses, gateway and Horizon configurations.   Once you get a working config you end up with an easily repeatable and tweakable deployment process that typically takes about 3 minutes to stand up a new a completely functional UAG instance.  It's very much in the spirt of infrastructure as code, providing complete transparency.  We're not talking about standing up a physical device, giving it an adorable name, and marveling at it's mysterious and obscure workings.   We know how these UAG instances work.  It's spelled out clearly in an ini file that's reliably leveraged throughout various instantiations and upgrades.  











The first steps for most customers is to initially deploy a UAG appliance using an OVF wizard through vSphere, then fine tune the appliance configuration through it's web interface.  Once they have a working instance setup, they export the configuration settings from the web interface, and voila,  a working, reusable ini based config is available for redeployments, updates and scaling.  Backups of a specific UAG instance amounts to one of these ini files, certificates, and standard downloaded .ova for the specific appliance version.  Line these three resources up on a command line, and you're good to go with a redeploy in 3 minutes.  Tweak out names of the appliance and ip address, and you've got your 2nd, 3rd, 4th, or 5th UAG in the works.   With each UAG handling up to 2K sessions, logically you're entire UAG deployment adds up to a handful of ini's, certificates and downloaded .ova files.   Upgrades amount to downloading a new .ova, tweaking out the the .ova path of your ini's and redeploying through PowerShell.   New UAG instances are spun up behind the load balancer, while older versions are placed in a special Quiesce Mode as they're slowly drained of sessions and eventually decommissioned.  All of this can occur with zero downtime.   

When you get a process like this in place you get machine like reliability that rarely falters outside of environmental disruptions from dependencies like load balancers, ssl certs or the network.   In a nutshell, supporting infrastructures typically wears out before the UAG's do. If there is a challenge suspected with the UAG instance itself, one of the first troubleshooting steps is to redeploy. With UAG deployments being repeatable and largely uneventful affairs, redeploys are commonly leveraged both for migrations to newer versions and troubleshooting purposes.  This shift to a fluid, infrastructure as code, model is daunting at first, but with some planning and elbow grease, yields a reliable and transparent remote access solution that leverages and benefits from vSphere infrastructure.  Backups are a piece of cake, upgrades are non events and replicating deployments for new environments is straight forward.  Generally speaking, if something breaks, it's usually cause someone has done something stupid with a dependency.  (Can you tell I love this solution? I do. Don't even get me talking about it when I'm drunk. I'll call it folksy and blue collar, sexy and a little bit edgy.) 


Meeting Load Balancing Requirements For UAG 

In typical deployments UAGs are placed within a DMZ between firewalls and 3rd party load balancers.  Along with enabling redundancy load balancers are key to the zero down time upgrades described in the previous section.  When comparing UAGs to NetScaler this requirement for external load balancing is one of the most common features gaps called out.  Fortunately, you can use one of the gazillion load balancers in existence to address this challenge.  Most customers I've interacted with have enterprise grade load balancers in place long before Horizon enters the picture.  Fortunately, load balancing requirements for UAG are straight forward and, to date, I've never come across a situation where an enterprises grade solution wasn't able to accommodate UAG.   The requirements are clearly spelled out in the article, Load Balancing Unified Access Gateway For Horizon.   Further, many vendors have their own processes specifically documented, such as this article from F5.   There's even solid guidance on leveraging NetScaler's load balancing capabilities for UAG, such as this article from the venerable Carl Stalhood.     
















All that said,  if you're looking for a new load balancing solution VMware's is more than happy to sell you a software defined load balancing solution called NSX Advanced Load Balancer, what used to be called Avi Vantage.   It enables elastic scaling and provisioning of load balancing functionality through service engines that are spun up and down across vSphere and native hyperscaler environments, with a software based Avi Controller centralizing control and management.  When it comes to standard load balancing or global load balancing, it's competitive with any other load balancing solution you might run across, including NetScaler.   Most notably, it's incredibly cost effective, enabling agile right sizing of load balancing capacity across vSphere and cloud environments, mirroring the agility offered through UAG.  It's a compelling  alternative to traditional hardware based load balancing solutions, so much so that NetScaler felt threatened enough to try and sue Avi out of existence back in 2017, a law suit that was eventually settled.   For a more in depth primer on NSX Advanced Load Balancers, check out this article I wrote in 2020.   Further, as with many other load balancing vendors, there's UAG specific load balancing guidance provided in the article,  NSX Advanced Load Balancer for Load Balancing UAG Servers



Finally, while NSX Advanced Load Balancer and many other 3rd party solutions provide global server load balancing (GSLB), if your GSLB requirements are limited to Horizon there's a purposed built SaaS solution called Universal Broker.  It works by leveraging the cloud based Horizon Control plane for authentication and intelligent routing of sessions across separate Horizon PODs.  Horizon protocol traffic is bifurcated, with the primary protocol working against a cloud based URL and display protocol traffic traversing UAG appliances.  Universal Broker is part of a larger initiative to enhance Horizon environments with cloud based services.  While it isn't for everyone, it's a beautiful example of VMware offering a SaaS based alternative for functionality traditional delivered on-premises.  For more information, check out this primer on Universal Broker, The Innovation And Current Limitations Of VMware's Universal Broker For Horizon



Honestly, I don't hold much allegiance to any load balancing solution when it comes to designing Horizon environments.  Quite frankly, for Horizon deployments I conceive of load balancers as a commodity, with the selection of vendor preordained by whatever solution customers already have in place.  Though it's critical to get load balancing setup properly, there's not a lot of room for creativity or differentiation in terms of Horizon outcomes.  It's more science than art.  


Stronger Forms Of Authentication For Horizon Remote Access

Passthrough is the default authentication method for UAG deployments.   Via the primary Horizon protocol, prior to the display protocol connection, AD credentials are passed through the UAG appliance onto the Horizon Connection servers, then executed against the AD environment the Connection server is joined to.   While this is the default behavior, most organizations augment this security one way or another.   For additional authentication from within the DMZ there's options for smart cards, certificates, RADIUS based solutions and RSA.  There's also built-in support for OPSWAT endpoint compliance check.  Historically, RADIUS based integrations with 3rd party MFA solutions have been very popular, allowing for simple integrations with solutions like Duo or Symantec VIP.  However, over the last few years direct SAML based integrations with solutions like Okta, Ping and Azure have become more popular, with support for such integrations starting around 2019.  










While direct integrations between UAG and 3rd party solutions are apt to get the job done, a more ideal method for accommodating stronger forms of authentication is through Workspace ONE Access.  WS1 Access is like Storefront in that it provides a catalog, a simple grid of icons through a browser for folks to consume.  However, WS1 Access also acts as an IDP and policy engine, enabling federation with popular SaaS solutions like like ServiceNow or Office 365, while also supporting integration with 3rd party MFA solutions.   It's policy engine is leveraged to enforce contextual authentication requirements for Horizon, integrated Citrix environments, and any federated SaaS solutions.  It's an ideal mechanism for wrapping modern authentication around Horizon environments enterprise wide, enforcing security policies when Horizon is consumed from the WS1 catalog or directly accessed through the Horizon client.  












My favorite way to describe WS1 Access is that it acts as sort of an integration goo, allowing folks to leverage authentication solutions they already have in place.   Through the WS1 Access Connector that's deployed on-premises AD environments are easily integrated with.   Further, the connector has built in support for RSA and Duo, while allowing integrations to other 3rd party MFA solutions through RADIUS.  The cloud based WS1 Access tenant itself can easily integrate with more modern MFA solutions provided by vendors like Okta, Ping and Azure through SAML federation, a very popular path forward nowadays.  Most notably, for existing WS1 UEM customers, WS1 Access provides a built in integration allowing customer to extend WS1 UEM based security to Horizon access.   This includes certificate based auth methods for Win10, macOS, iOS and Android, with an option to calibrate authentication requirements based on signals from underlying devices leveraging WS1 UEM's device compliance policies.   In addition, WS1 UEM integration introduces an option to leverage VMware's own MFA solution Verify (Intelligent Hub).   Finally, WS1 Access can drive it's contextual authentication policies bases on analytics from WS1 Intelligence like Login Risk scores or device risk scores.   Big picture, as a policy engine, WS1 Access allows us to enforce different authentication methods based on the context of the users, enabling admins to calibrate and right size security based on user and device context.   For more background on WS1 Access check out these intro and deep dive videos on Youtube put out by VMware's healthcare focused EUC team. 













Through these policy based controls WS1 Access enables us to wrap Zero Trust security around legacy windows.  Access to full desktops or individual published applications are firmly controlled and tracked through contextual access policies.  To further this Zero Trust adoption, we can inform these controls with device posture information and analytics from both WS1 UEM and Intelligence.  With such a deployment, Horizon is combined with Access, UEM, and Intelligence to create a superb remote access solution uncannily aligned with NIST Zero Trust guidance.  This ideal model is easily achieved by layering SaaS based instances of Workspace ONE services on top of Horizon environments, starting with the SaaS based version of WS1 Access included with Horizon Universal licenses.  














(NetScaler + UAG) In The Meantime Or Indefinitely  

As mentioned earlier in this post, it's perfectly feasible to load balance UAG appliances with NetScaler.  In fact, for many existing NetScaler customers it's an ideal and natural path forward.   Quite often I hear the objection, "but I've already paid for these NetScalers and they're on a different renewal cycle than Citrix itself."  Well, that's my kind of problem!   The option to continue leveraging NetScaler appliances while migrating from Citrix to Horizon helps limit the scope of change during a major migration.  Admins can focus on migrating the Citrix functionality itself without having to rip out load balancers or replace other NetScaler functionality at the same time, breaking down the overall transition into smaller bite size pieces.  In the short term, continue leveraging NetScaler while adding load balancing support for UAG appliances.  Chip away at your Citrix to Horizon migration first, then circle back later to replacing the NetScaler appliances if that's your eventual goal.  












Or don't get rid of NetScaler at all. If you're happy with NetScaler and feel satisfied you're getting value out of it independently of proxying Citrix sessions, shoot, keep it.  It's always possible your org is truly in need of a multi-purpose application delivery controller across the enterprise and NetScaler is fulfilling that function.  Granted, that's usually not the case with my customers.  Most of my customers are using NetScaler simply to proxy ICA sessions and maybe a little load balancing. Those organizations in particular should consider alternatives.  However,  if you are full-bore using advanced features of NetScaler across you entire enterprise and don't want to consider replacing this functionality AND you've made it this far through my article, heck, keep on keeping on.  Treat Horizon and UAG as simply another solution to load balance and you're all good in the hood.   In this situation, my best piece of advice would be to consider making the rest of the organization help flip the bill for the NetScaler functionality they're leveraging outside of Citrix remoting. 


Credit Where Credit Is Due 

In all the talk about Citrix superiority and success a key ingredient, the secrete sauce, is left out: the Citrix admins.  These are the folks who know the special registry keys, the idiosyncrasies of specific apps, the weakness and strengths of organizations that need to be navigated to successfully deliver an app.  Citrix admins are some of the most grizzled, experienced and knowledgable folks in the enterprises they work for.   In a cliche and cringy caricature of corporate sleaziness, they're contributions, and those of their supporting shops, are attributed to Citrix, as if the solution stood itself up and flawlessly began accommodating the needs of the business without any input.   The fact of the matter is that when you're marveling at a successful Citrix deployment, whether you realize it or not, you're marveling at the hard work, elbow grease and cumulative efforts of Citrix admins and their IT organizations.  This is a reality that is typically completely lost in discussion about Citrix vs Horizon.  So, as my contribution to this eternal debate, I'd like to call out that Citrix and Horizon are solutions sold business to business, while the IT shops themselves are what make their implementations successful.    

"You can't live without me," is the common refrain of psychopaths, wife beaters, and salesmen with coke habits and mistresses to feed.  For quite some time now, but particularly in the year 2023, saying you can't run a business on Horizon instead of Citrix simply is not true.  Personally, I deployed Horizon to an emergency room in 2011, so I have little tolerance for such hyperbole.  Saying an organization with the capacity to support Citrix couldn't be successful with Horizon is frankly down right insulting.  Yes, the migration will be quite involved. Yes, some processes will be changed.  But can it be done?  Hell yes, absolutely, 100%, especially if current Citrix admins are on board.  Further there's a lot of operational efficiencies and cost savings to to be gained with technologies like Instant Clones, App Volumes, and Horizon Published Apps On Demand.  Most notably, there's a real opportunity to modernize your remote access strategy using the standard functionality included in Horizon as well as solutions across the VMware portfolio.   

UAG or UAG combined with WS1 Access meets the majority of Horizon remote access needs while introducing the benefits of SaaS and infrastructure as code.  It stands in stark contrast to standing up another physical piece of hardware or complex appliance on-premises.  In addition, it opens the door to a clear and proven path towards Zero Trust adoption, arguably a future requirement for all of us. Further, both UAG and WS1 Access come standard with Horizon Universal licensing at no additional cost.   For organizations using advanced NetScaler capabilities there's some careful analysis of functionality and cost to explore.  If you really are leveraging some of it's more unique and compelling features to run your business you can continue to use NetScaler after migrating to Horizon.  However, most customers stand a great deal to gain from exploring alternatives from VMware or VMware's partners.

Wednesday, May 3, 2023

VMware Horizon's Uncanny Alignment With NIST Zero Trust Guidance

The foundational components for Zero Trust architectures such as MFA, ICAM and endpoint security are solutions widely deployed today.  While most organizations already have these building blocks in place achieving Zero Trust objectives with their aggregate capabilities requires a level of orchestration and synchronicity that is far less common.  In that regard, the integration and orchestration of a broad set of security components through a single platform, the Anywhere Workspace, is something VMware has been perfecting for over a decade now.  To modernize legacy windows experiences Horizon is combined with Access, UEM, and Intelligence to create a superb remote access solution uncannily aligned with NIST Zero Trust guidance.  Such a deployment meets the immediate need to optimize support for a hybrid workforce while establishing a beachhead for further Zero Trust adoption.














This post maps out Anywhere Workspace Zero Trust capabilities to guidance provided by NIST and it's subsequent work with the National Cybersecurity Center Of Excellence (NCCoE).   The intent is to elevate a discussion about Horizon and Zero Trust by referencing a source respected and followed across the public and private sector.  With federal agencies like CISA, DoD and the NSA paying deference to NIST guidance, along with it's reference by executive order 14028, treating NIST as authoritative on the topic of Zero Trust is hardly controversial and can help ground a discussion. Accordingly, this post provides a primer on NIST guidance with a focus on the notional Zero Trust architecture first introduced in (SP) 800-207, then practically demonstrated in Implementing A Zero Trust Architecture.  It then compares logical components of this conceptual model to a Horizon architecture leveraging the full breadth of Anywhere Workspace Zero Trust capabilities.  This should be of interest to anyone looking to enhance windows desktops or applications with Zero Trust security, and, if nothing else, will enable Horizon admins to articulate advancements toward Zero Trust already achieved with their deployments.


A Primer On NIST Zero Trust Guidance 

Most descriptions of Zero Trust start by declaring a need to shift from perimeter based network security to a model where hostile actors are always presumed present and within reach.  Accordingly, instead of protecting networks the focus is on controlling access to the critical resources themselves through policy based controls that continually evaluate users and their requests. As the abstract for NIST (SP) 800-207 states, “Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”  While this article focusses on guidelines put forth by NIST and NCCoE, I'd like to call out the folksier description of Zero Trust laid out by MobileJon.  For most organizations Zero Trust adoption entails a recognition that firewalls and kerberos based security provided by Active Directory no longer cut the mustard given what we know about today's threats.

Mobile Jon's Guide To Zero Trust Security

To replace perimeter based network security (SP) 800-207 introduces a notional architecture detailing logical components required to achieved Zero Trust objectives.  In the more recent NIST/NCCoE publication,  Implementing A Zero Trust Architecture, example deployments illustrate how commercially available solutions are used to achieve these ZTA objectives.  This series of guides, "demonstrate several example ZTA solutions—applied to a conventional, general-purpose enterprise IT infrastructure—that are designed and deployed according to the concepts and tenets documented in NIST Special Publication (SP) 800-207, Zero Trust Architecture." The core functionality driving these ZTA demonstrations is illustrated below: 

Zero Trust Architecture, NIST 802-207
At the top of this model there's the brains of the entire operation, the Policy Decision Point (PDP), made up of a Policy Engine (PE)  and Policy Administrator (PA).  The Policy Engine makes the determination of whether or not a subject is granted access to a given resource.  It works in tandem with a Policy Administrator responsible for executing it's decisions.  To this end the PA helps establish the communication path between subject and resource, going on to, "generate any session-specific authentication and authentication token or credential used by a client to access an enterprise resource."  Finally, there's the Policy Enforcement Point (PEP) working in conjunction with the Policy Administrator to allow or deny connections between the subject and resource.  While there's certainly more details, this is the high level model proposed by NIST for enabling Zero Trust security. 

To make informed decisions about access requests the Policy Engine processes input from various sources, what are referred to as Policy Information Points (PIP). Data from these sources is ingested into a trust algorithm that determines whether a specific request to a resource should be allowed.  Examples of PIPs include endpoint antivirus, endpoint management and security analytics solutions.  PIPs contribute to a more comprehensive, 360-degree, contextual model for continually assessing the trust worthiness of a subject.  We're not just talking about defense in depth, but rather the coordination and orchestration of various security solutions into a comprehensive model.   

Implementing A Zero Trust Architecture (Fact Sheet)
While (SP) 802-207 establishes a high level framework for Zero Trust, Implementing A Zero Trust Architecture goes into the nitty gritty of how these PIPs are pieced together with PAs, PEs and PEPs to deliver Zero Trust objectives.  Currently there's 5 sample architectures total, 3 of which are referred to as crawl phase architectures, E1B1, E2B1 and E3B1.  These first 3 builds focus on enhanced identity governance (EIG), what's viewed as a, "foundational component of ZTA."   Then, there's 2 more run phase architectures, E1B2 and E3B2,  that build upon the crawl phase.  Eventually the plan is to introduce additional advanced architectures with capabilities like micro-segmentation. "After completing the EIG crawl phase builds, we enhanced these implementations by adding specialized PE and PA components, device discovery, and cloud-based resources in the EIG run phase. In future phases, we plan to introduce capabilities such as software-defined perimeter and micro-segmentation."  Here's a graphical representation of crawl phase architecture E1B1, featuring Okta and Ivanti:

Implementing A Zero Trust Architecture, Volume B: Approach, Architecture and Security Characteristics













Again, while there's only 5 example architectures today the publication is a work in progress and there's additional examples planned for the future.  If I had the option I'd bet large sums of money that VMware products will eventually find their way into future architectures.  More conspicuous than the absence of VMware products in the current publication are the listed contributions of VMware employees in 1800-35B.  One of these five is Peter Bjork, a very high profile evangelist of VMware's Zero Trust capabilities.  While something more exhaustive and definitive might come out in an update to the publication, as a blogger and long time fan of VMware EUC I'm going to take a swag at mapping Horizon and Workspace ONE components to the notional ZTA architecture put forth by NIST.  


Mapping VMware EUC Components To A Notional ZTA 

To those familiar with VMware's EUC stack the notional ZTA put forth by NIST can come across  like a fun adaptation or clever spin on architectures put out by VMware for about a decade.   Personally, reading NIST documentation on ZTA felt like deja-vu. (all over again)  With it's identity capabilities, federation options and conditional access policies, Workspace ONE Access clearly fits the bill as a policy decision point (PDP), acting both as a policy engine (PE) and policy administrator (PA).  These identity based policies for controlling access to resources are further enhanced by solutions like WS1 UEM, WS1 Inteligence and Carbon Black.  While these provide relevant security capabilities in their own right, as sources of data providing context for access policies they're clearly acting as policy information points (PIP).  Finally, sitting between endpoint devices and virtual desktops on the data plane is Unified Access Gateway acting as a policy enforcement point (PEP). 

For over a decade WS1 Access has offered admins a way to wrap modern authentication around Horizon. It's policy engine is driven by conditional access policies that enforce an adaptable set of authentication requirements based on user context.  Some of these auth methods are built-in, some arise from a combination of Access and UEM, and others are available through 3rd party solutions via RADIUS or SAML based integrations.   While Access supports several federation standards, SAML 2.0 is definitely the star of the show, key to it's policy administration for solutions like Horizon.  Once a subject has met the requirements of these conditional access policies they're issued a SAML assertion granting access to the Horizon environment.  











The ability to drive adaptable authentication requirements through a policy engine has always been a major selling point for WS1 Access.  It's conditional access policies for each application are initially defined based on a user's AD membership, general device type, and IP range a request comes from.  This contextual insight is extended to device posture through a simple integration with WS1 UEM that incorporates device compliance status into conditional access polices.  Historically referred to as, "conditional access based on device compliance," this functionality is achieved through a combination of certificate auth and UEM's device compliance policies.  It's an option VMware has offered for about a decade now, functionality foundational to Zero Trust that's mandated by pretty much all sources on ZTA.  For example, in BeyondCorp A New Approach to Enterprise Security, a similar approach to incorporating device context is called out, with unique certificates on managed devices used as a conduit to device information. "While the certificate uniquely identifies the device, it does not single-handedly grant access privileges. Instead, it is used as a key to a set of information regarding the device." 

Access can also ingest data from Workspace ONE Intelligence regarding device and login risk, further extending the contextual insight of it's policy engine.  Both solutions represents the results of analytics run against data collected into the Intelligence data lake from Access or UEM.  Device Risk Score is driven by factors like OS patching, anomalous configuration and detected threats on a device.  Login Risk Score, "uses machine learning models to analyze past user login patterns and determine if a login attempt is anomalous." Collectively, these risks scores represent additional policy information points to further calibrate our conditional access policies by. 



















Finally, there's my favorite bouncer Unified Access Gateway (UAG). Like any good bouncer it's lean on brains but intimidatingly hardened and experienced. Working in coordination with Access and Horizon Connection Server it guarantees all proxied Horizon display protocol traffic is on behalf of subjects vetted by conditional access policies.  In this capacity it acts as a policy enforcement point (PEP) for remote Horizon Connections.  Below is an illustration of how it facilitates SAML based authentication between Access and an internal Horizon environment prior to proxying display protocol traffic to a virtual desktop or RDS host. 

Setting Up Resources In VMware Workspace ONE Access




























The specific model above has been alive and well for over 6 years now, having replaced a legacy Security Server based model that itself was about 5 years old.  Again, an example of Zero Trust functionality Horizon customers have had in place for about a decade. 

By encapsulating the windows experience into an portable and secure service Horizon provides a catch all solution for extending Zero Trust capabilities to legacy windows apps.  Any windows desktop experience or windows app delivered through Horizon can be wrapped in modern auth that's driven by a contextual policy engine.  This is no small feat.  We're talking legacy applications that rarely support modern auth butting heads with the Zero Trust requirement for extended identity governance.   Horizon bridges this gap to meet a fundamental requirement for ZTA.   In addition, there's many features of the stand alone Horizon solution, such as Instant Clones, that clearly advance the pursuit of Zero Trust.  Non-peristent Horizon models isolate an endpoint device from windows workloads and introduce critical containment that reduces the blast radius of any potential compromise in terms of both space and time.  The inherent security awesomeness of Horizon itself and it's contribution to Zero Trust outcomes is something I will detail in a future post. 


A Clear Path Forward For Existing Horizon Customers

Existing Horizon customers can progress towards Zero Trust adoption by making incremental improvements to their remote access experience for windows workloads.  This fulfills the immediate and practical need to support a hybrid workforce while developing capabilities for Zero Trust adoption across the board.   Customers who own Horizon Universal licensing already have the key ingredients for getting started on this journey, Horizon, UAG and WS1 Access.  These solutions meet core ZTA requirements and can later be augmented with UEM, Intelligence and Carbon Black.  This process of wrapping Zero Trust security around your windows experience is easily adapted to secure SaaS solutions like Office, Salesforce, ServiceNow, Workday or Google Workspace.  













With this framework in place you can increase SaaS adoption while expanding your Horizon deployment and shrinking the trusted network.  Further, the path forward includes incremental wins along the way that our tangible and hold value in and of themselves, allowing you to eat this elephant one bite at a time.  No one complains about having a unified catalog and providing SSO only makes friends.  MFA is something we all know is necessary and extending it's reach while minimizing disruption amounts to rolling up your sleeves and taking care of business.  Right sizing your security based on context is just good manners.  Mandating device enrollment for sensitive services is hardly controversial.   These steps represent small but very tangible wins as you progress along your Zero Trust journey.  Eventually, in a perfect world you'd have a combination of Horizon, Access, UEM, Intelligence, Carbon Black and NSX protecting workloads from endpoints to the data center.   











Some Excellent VMware Collateral On Zero Trust Adoption 

VMware provides some very impressive guidance on Zero Trust, particularly in Tech Zone.  In respect to NIST SP 800-207, EO 14028, and their impact on the federal space there's a great article by Andrew Osborn called, Incorporating VMware Zero-Trust For the Presidential Executive Order. It offers a summary of cybersecurity mandates and models created to guide federal agencies in their adoption of Zero Trust.   These include CISA's Cloud Security Technical Reference Model and Zero Trust Maturity Model.  At the end of the article Andrew states, "VMware will be augmenting our solution alignment and future whitepapers to incorporate the new CISA foundational pillars."  

Zero Trust Maturity Model 2.0

True to this promise is one of my favorite articles on Zero Trust and Horizon,  Zero Trust Secure Access to Traditional Applications with VMware.  It provides a very thorough and exhaustive account of how different capabilities across the Anywhere Workspace stack can contribute to a Zero Trust architecture for legacy windows applications.  It organizes these capabilities according to 5 pillars of trust.  They might look familiar to you.









Along the same vein there's an article on the use of VMware Tunnel for access to on-premises web applications called, Zero Trust Secure Access to On-Premises Web Applications with VMware.  Similar to the Horizon focussed article it provides a detailed and exhaustive account of the Anywhere Workspace capabilities that enable Zero Trust security for on-premises web apps.  Finally, anything put out by Peter Bjork is likely to further your understanding of Zero Trust capabilities offered by VMware. With extended identity governance at the core of Zero Trust, his expertise in WS1 Access is highly relevant.  


Conclusion 


To quote chief justice Earl Warren, “Everything I did in my life that was worthwhile, I caught hell for.” Implementing Zero Trust isn't going to be fun, will involve a lot of work and invariably is going to frustrate some people.  It's an interdisciplinary undertaking transcending traditional IT silos filled with hyper-focused specialist who don't get paid to think or care about the big picture.  Success will require grit and confidence while striking a balance between the status quo and need to transform security.  In a situation like this a mature platform integrating a broad set of capabilities really shines.  With the Anywhere Workspace we gain a guaranteed level of interoperability amongst separate components needed to realize a Zero Trust architecture.  Instead of sweating details about interoperation why not pass the work off to a single vendor with a solution that has aligned with NIST guidance for over a decade, long before (SP) 800-207 was even published?  It's a path forward most existing Horizon customers can pursue with components already owned and in place.   

Wednesday, November 30, 2022

The Innovation And Current Limitations Of VMware's Universal Broker For Horizon

VMware's Universal Broker allows Horizon users access to multiple Pods through a single URL, routing sessions based on resource availability, entitlements and shortest network paths.  Traditionally, multi-site Horizon deployments require a combination of Cloud Pod Architecture (CPA) and 3rd party global load balancers to provide fluid failover and fall back.  Universal Broker, part of the Horizon Control Plane, replaces these requirements with a purpose built SaaS based offering.  The solution leverages the control plane's privileged insight into Horizon environments to deliver more efficient and error free placement of Horizon sessions across Pods.  This addresses shortcomings of traditional CPA/GSLB deployments while laying the ground work for integrating Horizon deployments across various cloud vendors.  



All that said, there are certainly caveats and limitations to the solution.  In fact, you might say there's a conga line of caveats and limitations.  However, while the technology is currently going through an awkward teenage phase of sorts, overall its a clever and compelling solution with a promising trajectory. It's not just a one for one replacement for CPA and 3rd party GSLB.  Universal Broker is an elegant innovation, a purpose built SaaS based solution for Horizon that parlays environmental information from the control plane into more efficient and error free placement of sessions.  Key to its efficacy is an innovative bifurcation of the Horizon protocol, with the primary and secondary protocols following separate network paths.  This shift helps avoid the need for east-west replication traffic between Horizon Pods, as is the case with CPA.   Further it solves for a particularly acute affliction with east-west interpod traffic called Horizon protocol hair-pinning, a potential pitfall for the traditional combination of CPA and 3rd party GSLB.   Overall, Universal Broker simplifies and improves on-premises multi-site deployments while enabling the effective adoption of Horizon 8 cloud based workloads.  It's also integral to the new next-gen Horizon Control Plane currently supported for Horizon on Azure. This post will provide a brief overview of Universal Broker, the hair-pinning challenge it addresses, its setup for Horizon 8 environments and some current limitations.  

The Innovation Of Universal Broker For Horizon

Along with making it easier to deploy and support the cloudiness of Universal Broker is key to more efficient routing and placement of Horizon sessions across Pods.  As part the Horizon Control Plane it has privileged information about home sites, resource availability, and established sessions, affording its global load balancing functionality a greater degree of integration with Horizon.  Traditionally 3rd party GSLBs and CPA at best can be well coordinated with Horizon, but nothing near the synchronization achieved through Universal Broker.  A further departure from the traditional model is how Universal Broker bifurcates Horizon protocol traffic into two separate network paths.   The primary Horizon protocol traffic, which handles authentication, travels between the client endpoint device and Universal Broker in the cloud.  The secondary Horizon protocol traffic, the display protocol, traverses a second path between the client and actual Horizon environment.  
















For context, below is a representation of the flow of Horizon protocol traffic for a normal remote Horizon connection.  Typically the primary protocol traffic is over TCP port 443 from the endpoint client through the Unified Access Gateway (UAG) appliance onto the Connection server.  If this authentication is successful the Horizon secondary protocol kicks into gear, establishing a display protocol connection between the endpoint client and the virtual desktop.   Under normal circumstances, using the Blast display protocol, this would consist of 8443 UDP based traffic to the UAG appliance and 22443 UDP traffic from the UAG appliance to the virtual desktop.  









With Universal Broker the Horizon protocol is bifurcated, traveling across two separate network paths.  The primary Horizon protocol consists of a connection directly against Universal Broker for authentication over TCP 443.   After successful authentication the secondary Horizon protocol traverses a connection between the endpoint device to the Horizon Pod itself.  Again, under normal circumstances for Blast it would be UDP 8443 to the UAG appliance and UDP 22443 from the UAG appliance to the virtual desktop.   Overall, we're talking about two very separate network paths.  One from the endpoint device to the Universal Broker service in the Control Plane and a second path from the endpoint device to the Horizon environment itself.  









So, when Universal Broker is in the mix the entire primary Horizon protocol connection is shifted and offloaded to the cloud.  Though, relatively speaking the vast majority of Horizon protocol traffic is secondary protocol traffic, this shift of the primary protocol traffic is still significant, simplifying support of initial connectivity.   If a user fails to authenticate to their Horizon environment through Universal Broker you don't need to investigate site specific challenges providing external world access to Horizon services.  No load balancers to troubleshoot, no questions about client network connectivity to your on-premises environment and, if you leverage a subdomain of vmwarehorizon.com, no concerns about DNS records or expired certificates.  All these typical primary protocol concerns are offloaded to Universal Broker.  If the user is failing to see their entitlements most likely they're fat fingering their password or just failing to have access to the internet.  By shifting the primary protocol exchange to the cloud a lot of the nittier grittier troubleshooting for remote connectivity is circumvented or at least simplified.  

The Horizon secondary protocol, the display protocol, is most relevant and impactful when it comes to user experience.  Fortunately, the network path traversed by this protocol is established post authentication based on Universal Broker's assessment.  An optimum Horizon Pod is judiciously selected based on, "insider information," regarding the status and configuration of the Horizon environment and entitlements.  This leads to global load balancing that's better informed by the Horizon solution, providing a tighter integration than normally achievable.   It's easy to appreciate this improvement when you consider an esoteric pitfall of the older traditional GSLB/CPA model: Horizon protocol traffic hair-pinning.  


Horizon Protocol Traffic Hair-Pinning - Ouch!

For over a decade now VMware has offered a fully redundant Horizon architecture for customers who need a bullet proof, highly available Horizon deployment. It used to be referred to as, "AlwaysOn Point Of Care," in homage to the healthcare customers that were particularly fond of the solution. Nowadays, it's consider just plain redundancy, or a Horizon Multi-Site architecture. Prior to Universal Broker, an absolute requirement for this architecture was some combination of a 3rd party global load balancer and Cloud Pod Architecture (CPA).  The GSLB solution provides a single name space for multiple sites, while CPA replicates entitlements, resource status and current session information between the separate Horizon Pods, providing minimal integration between otherwise fully redundant and independent Horizon environments.  This ensures fluid failover and fall back in response to disruptions and outages, while also ensuring folks get properly routed according to home site preferences or pre-existing sessions.  



This model has been good enough to make it throughout the last decade but has a couple caveats less than ideal for traditional on-premises deployments and complete deal breakers for certain types of cloud based deployments. First off, it's predicated on network connectivity and east-west traffic between Horizon Pods, a requirement for replicating entitlements, resource availability and session status across separate environments.  It's a potential challenge when you consider these Pods could be very far away from each other or on different clouds.  








While CPA traffic isn't too extensive and is typically manageable,  the need for east-west traffic between sites can really spike when remote connections through UAG appliances are in the mix and global load balancing isn't executed flawlessly.  This ties back to UAG and how it handles the Horizon protocol.  Traditionally you must have both the primary and secondary Horizon protocol traffic go through the same UAG appliance.   In fact, outside of Universal Broker deployments, it's an absolute requirement.  UAG's prime directive is to ensure all display protocol traffic passed is on behalf of a strongly authenticated user.  To achieve this it only passes secondary protocol traffic for sessions its handled primary protocol traffic for.  There's no way for UAG to communicate authenticity of a Horizon user to other UAGs.   So, under normal circumstances, the same UAG that handles primary protocol traffic must handle the secondary protocol traffic or the session will otherwise break.  This is by design.  Now, this requirement for UAG can have some rough consequences in the context of a traditional Horizon multi-site architecture.  If the 3rd party global load balancer doesn't do a flawless job getting folks routed to the proper Pod, there's potential for an inefficiency referred to as Horizon protocol traffic hair-pinning.  

For example, say an organization has two PODs, one in New York and one in Los Angeles.  Then a jet setting banker working for that organization connects to his virtual desktop from a Manhattan penthouse.  Accordingly, the GSLB routes him to the Horizon POD in New York.   He disconnects from his virtual desktop, kisses his wife and kids good bye, then jumps on a private jet with his mistress for a weekend getaway to the Grand Teton National park in Wyoming.   When he reaches the hotel room in Wyoming he remembers, "oh shoot I forgot a quick thing for work," then connects to his Horizon environment.  The global load balancer sees he's in Wyoming and routes him to the closer California Pod.   He hits the Horizon Connection server in California and through CPA the Connection Server is aware of the banker's currently open session in New York.  It routes him back to that currently open session.  Great, except, because he's initially connected the California Pod through a UAG appliance in California, he has to continue using that UAG appliance.  So his traffic has to go from Wyoming to California, then back across the US from the UAG appliance in California to the Horizon Pod in New York.  An extreme but perfect example of Horizon protocol hair-pinning.   Not only could it make for a lousy user experience, but it could lead to an excessive amount of east-west traffic beyond what's been planed for.  












This example is extreme, but by no means outside the world of possibilities.  There's certainly ways you could fine tune the coordination of your 3rd party global load balancer and Horizon environments to mitigate this challenge.  (For instance I've heard F5 has an APM module that can more accurately route a user to a Pod where they already have an established session.)  However, I don't think creating a GSLB/CPA solution that's bullet proof is a cake walk and that's why this challenge is called out in the Tech Zone article, Providing Disaster Recovery for VMware Horizon.   If you don't get things just right the impact could be fairly brutal on your user experience and networks, possibly in the middle of an outage, when hair-pinning challenges are the last thing you need.  Potential for particularly acute challenges arise when considering cloud hosted desktops.  Both the AWS and GCVE guides warn against this potential hair-pinning.  In these scenarios, hair-pinning has the potential to saturate capacity on NSX gateways and kill session density.   Further, it could lead to some expensive and senseless traffic flow between on-premises and cloud environments.  Accordingly, it's recommended to leverage Universal Broker instead of CPA for these Horizon 8 based cloud deployments. 











Despite working with Unified Access Gateway for over half a decade now I was completely blind sided by this esoteric gotcha.  It took awhile for this challenge to sync in, but when it did, oh boy, did it!   Fortunately, we can completely side step this potential pitfall by adopting Universal Broker.  With Universal Broker no traffic hits a UAG appliance until after there's been a successful authentication against the cloud and an ideal path has been determined.   So, with the adoption of Universal Broker we avoid this esoteric, but real, pitfall with on-premises Horizon environments while laying the ground work for successful multi-site adoption with cloud hosted virtual desktops.  Speaking of cloud hosted desktops lets talk about Universal Broker and it's role in the next-gen Horizon Control Plane for Horizon on Azure. 


Universal Broker And The next-gen Horizon Control Plane (Titan)

For the next-gen Horizon Control Plane, currently limited to Horizon on Azure, Universal Broker is an essential built-in component.  It plays a critical role in the transformation to a Horizon thin edge, helping eliminate the need to deploy Horizon Connection servers within Azure.  Instead, there's a light weight deployment of a thin Horizon Edge on top of native Azure, consisting of only UAG appliances and Horizon Edge Gateways.  The rest of the traditional infrastructure used to manage the Horizon environment is shifted to the next-gen Horizon Control Plane.  This reduces consumption of Azure capacity while simplifying the deployment and maintenance of Horizon.   










Again, with this next-gen architecture Universal Broker is an absolute requirement, an integral part of this new model. So much so, it doesn't even get specifically called out in the next-gen reference architecture or official documentation.  It's functionality requires no extra configuration and is assumed available as entitlements are created.  While this new, stealthier, iteration of Universal Broker is certainly easier to deploy it's only available with the next-gen Horizon Control Plane, so its limited to Horizon on Azure for now.   For those leveraging Horizon 8 deployments on-premises or on top of various SDDC public clouds - AVS, GCVE, AWS  - v1 of Universal Broker is still relevant. At Explore Europe 2022 VMware announced intent on extending next-gen architecture to Horizon 8, but it's limited in scope as of today and there's no committed time line for extending it's newer iteration of Universal Broker to Horizon 8.  In the mean time there's the traditional Universal Broker deployment that's been available for sometime now and, while it's not as easy to deploy as v2, it's not rocket science.  


Setting Up Universal Broker With My On-premises Lab 

Since the setup of Universal Broker for Horizon 8 is well documented I'm just going to provide a high level overview, call out some specific challenges, and include links to relevant documentation for those who want to get into the nitty gritty.   The official documentation calls out four major steps for setting up Universal Broker for Horizon 8 environments.  Assuming you already have a current version of Horizon Cloud Connector up and running, the next steps are:

  1. Installing the Universal Broker Plugin on all Connection Servers 
  2. Configuring your UAG appliances with the required JWT settings 
  3. Enabling Universal Broker in your Horizon Universal Console 
  4. Configuring multi-cloud entitlements within the Universal Console 

Again, these steps are well documented in both the official documentation for Horizon Cloud Control Plane and a really nifty Tech Zone article called, "Configuring Universal Broker For Horizon."   Below is an excellent graphical representation of the architecture.  
















While in hindsight the configuration of UAG was relatively straightforward I personally struggled with it. The relevant settings are configurable through the web interface for the UAG appliance by navigating to  advanced settings and clicking the gear box for JWT.  All the settings to input are in regard to the supported Horizon Pod itself and are specially detailed here in the documentation.  First off there's the cluster name of the Horizon Pod.  Unless you've bee supporting CPA, you've probably never been aware of this property.  Its case sensitive so use caution.  (I had challenges with this portion of the setup because CPA had been enabled for my Pod in the past, though it currently wasn't in use.  That had the affect of changing the name of the cluster that was displayed versus what was needed for the UAG setting.)  







Another setting I initially struggled with was the Dynamic Public Key URL.  This essentially amounts to appending "/broker/publicKey/protocolredirection" to the internal FQDN of your Horizon Pod.  (I would think it's always going to be the same FQDN used for your, "Connection Server URL," under Horizon Edge settings.)   Likewise, the, "Public key URL thumbprints," is the certificate thumbprint used by the FQDN leveraged for the Dynamic Public Key URL. (Again, probably the same as your Connection Server URL Thumbprint under Horizon Edge settings.).  So, overall, the values are fairly similar to values you you're using already for your UAG's Horizon settings, but they have weird fancy names that can throw you off.   For context, here's the settings I typically use for my Horizon Edge settings:









And here's the JWT settings for Universal Broker: 










In hindsight it all makes sense enough but in the context of setting up a new solution it was a bit confusing at first.  Another gotcha I  bumped into was the need to define your desktop pools as, "Cloud Managed," when initially creating them, prior to creating your multi-cloud assignments within the Universal Console.  Fortunately, once you know to do this, the procedure is simple enough.  As you're walking through the desktop pool creation wizard check the box for, "Cloud Managed," and you're good to go.













Again, there's a great article in Tech Zone that covers the the setup of Universal Broker called, "Configuring Universal Broker For Horizon."  I'm sorry to say I didn't learn about this articles existence till I was almost completely done with the setup.  Instead, I slogged through the entire setup using the official documentation, "Administration of Your Horizon Cloud Tenant Environment and Your Fleet of Onboarded PODs."  It was doable, just not the smooth and enjoyable guidance of a well put together Tech Zone article.  

Other portions of the setup were fairly straight forward.  For instance, installing the Universal Broker Plugin was just a matter of locating the right version for my Connection Servers, accepting defaults, and going next-next-finish.  Configuring the Broker service in the Universal Console was easy and straight forward as well, particularly because I choose to go with a subdomain of vmwarehorizon.com, rather than a customer provided FQDN.  This avoids the need to generate any SSL certs or create any external DNS records, which I found to be a lovely convenience.  (Otherwise, you can go with the customer provided option, then enter in your own FQDN and provide a cert.). 









With the plug-ins installed on your Connection Servers, UAG's properly configured and Broker enabled, you're ready to start creating your multi-cloud entitlements from the Universal Console.   It's a relatively straight forward process so I'll leave that to the official documentation.  


One final thing I'd like to point out is that you can configure UAG's to support Universal Broker, without disrupting their use for traditional UAG access to Horizon environments.   So folks can continue to hit these UAG devices directly for access to traditional Horizon pools while in parallel they can support access through Universal Broker.  Further, while the local pools used for Universal Broker multi-cloud entitlements are configured from Universal Cloud, the entitlements made from the cloud trickle down to the local pools so these local pools are also accessible through direct UAG connections. 


Current Limitations Of Universal Broker 

While Universal Broker presents some interesting innovation and a compelling future there's definitely some limitations.  Most notably, Universal Broker v1 doesn't support application pools across multiple Pods.  You can deliver a single Pod based application pool but you're not going to get load balancing for application pools across multiple Pods.    So, as far v1 of Universal Broker is concerned, there's isn't parity between application pools and virtual desktop pools.  Another limitation as of today is no support for mixing Horizon 8 based Pods and Horizon Cloud based Pods. (Horizon on Azure.)  So, for example, you can't have a multi-cloud entitlement that spans across an on-premises Horizon 8 Pod and a Horizon on Azure environment.   However, you could have a multi-cloud assignment that spans across an on-premises Horizon 8 Pod and Horizon 8 Pod running on top of AWS, GCVE or AVS.   It comes down to whether your deployment use traditional Horizon 8 Connection Servers or not.   If they do then they can share multi-cloud entitlements with one another. (Assuming they're not application pools.)

There's also challenges regarding support for stronger forms of authentication.  Leveraging the built in capabilities of UAG, there's support for RADIUS and RSA.  However, there's no support for smart cards or certificate auth.  Further, there isn't support for direct SAML integrations between UAGs and 3rd party IDPs, one of the fastest growing methods for strong authentication within the DMZ through UAG.  So no support for direct integrations with IDPs like Okta, Ping or Azure.   That said, there is support for Workspace ONE Access, which in turn can be integrated with this 3rd party solutions.   So Workspace ONE Access can be configured as a trusted IDP for Universal Broker, which in turn can leverage 3rd party solutions that have been configured as trusted IDPs for WS1 Access. (Kind of like the good old days before UAG started supporting direct integrations.).  

The integration of Universal Broker with WS1 Access makes for interesting discussion because there's a lot of confusion about the ability to replace the solutions with each other.  While there's some slightly overlapping capabilities in the two products, by and large they are complementary solutions with very different competencies.   Sure, Workspace ONE Access is a way to provide users with a single URL for access to multiple Horizon PODs,  but the solution is squarely focused on identity and wrapping modern authentication around Horizon access.  It's by no means a global load balancing solution.  Conversely, while Universal Broker can support strong authentication through RADIUS and RSA,  its core competency is providing global load balancing based on shortest network path, assignments and current Horizon environment status.  So, when you focus on the core competencies of each of these solutions, what they're really good at, combing the technologies is possibility worthy of consideration.   For a great overview of this integration, check out the section, "Workspace ONE Access And Horizon Integration," with  the Tech Zone article, Platform Integration.  Below is a great diagram of the integration.  

















However, there's an important caveat to be aware of.  With this WS1 Access integration, as it stands today, there isn't an option to configure unique WS1 Access policies for the multi-cloud entitlements supported by Universal Broker.  Buried in the documentation, under a section called, "Horizon Cloud - Known Limitations," it states, "access policies set in Workspace ONE Access do not apply to applications and desktops from a Horizon Cloud environment that has Universal Broker enabled." Instead, all the Universal Broker entitlements are protected by the default access policy of WS1 Access.  Depending on your deployment this may or may not be a deal breaker.   If you're using WS1 primarily for your Horizon deployment, and all your entitlements have the same access policy requirements, then having them all share the same default access policy could be feasible.  However, if you need granularity in terms of your WS1 Access policies for these multi-pod assignments, say stricter requirements for some specific pools than others, this could be a problem.   Or if you have a fairly mature WS1 Access deployment and want looser requirements for initial portal access it could be a challenge.  For more granular WS1 Access policies to use for your desktop you need to fall back to Virtual App Collections which, unfortunately, are incompatible with Universal Broker.   


The Trajectory Of Universal Broker And next-gen Horizon Control Plane

As called out earlier in this post, VMware recently announced plans to extend the next-gen Horizon Control Plane to Horizon 8 environments for better support of hybrid deployments across on-prem and Azure.   Given Universal Broker is transparent and built into the next-gen Control Plane, extending this new control plane architecture to Horizon 8 shows a lot of promise for addressing the limitations of Universal Broker v1 as of today.   Right off the bat, the next-gen Horizon Control Plane supports application pool entitlements across multiple Pods, addressing a long standing limitation.  Further, extending support to Horizon 8 certainly implies that challenges with multi-cloud entitlements across Horizon and Horizon Cloud PODs  will be addressed.  Finally, there certainly appears to be commitment to ironing out challenges combining Universal Broker functionality with Workspace ONE Access.  With this next-gen architecture, use of an IDP is no only supported, but is an absolute requirement.   As of today there's a choice between WS1 Access or Azure.  











Though there's no fixed promises made by VMware as of today, with this next-gen Horizon Control Plane and Universal Broker there's a clear trajectory towards addressing a lot of todays challenges.    


Conclusion 

While there's work to be done and gaps to bridge I'm still incredibly excited about the Universal Broker technology and think every Horizon admin should at least be familiar with it.  In some ways it reminds me of Instant Clones circa 2016 or UAG in 2015, back when it was called, "Access Point."  Both these solutions seemed a little crackpot or science project-ish at the time.  They weren't quite ready yet, not done baking till... they just were.  Though we definitely had our reasons for being suspect or dubious upon their initial release these solutions eventually rounded the corner and established themselves as standard technologies, core to the Horizon stack.  I think the case will be the same for Universal Broker simply because it has a lot going for it.  First and foremost, it's not a solution looking for a problem, but rather a purpose built solution for addressing a Horizon specific requirement.  More notably, the way it solves this challenge from the cloud makes it both clever and easy to deploy, while lending Horizon admins a greater degree of autonomy.  Eventually, its adoption will become the path of least resistance.  I wouldn't necessarily implore admins to rip out their current working implementations of CPA\GSLBs and slam this technology in.  However, as new multi-site implementations get stood up I think the customer base will slowly migrate over to this new solution.  By the time it becomes a new standard we probably wont even call it Universal Broker anymore.  It will just be multi-cloud assignments through the Horizon Control Plane, something we take for granted.