Setting up Horizon in a multi-domain architecture

VMware Horizon makes the delivery of virtualized desktops and apps easy and secure from on-premises or cloud hyperscalers such as Azure, AWS or Google. Users would typically authenticate to a single Active Directory domain or multiple trusted domains in a single forrest.

However, what if you are a managed service provider (MSP) who wishes to leverage Horizon to securely deliver Windows applications to multiple customers (Agencies)?

In many cases those agencies have their own (separate) Active Directory (AD) domains which is not in anyway connected to the MSP’s Active Directory. ie. the are NOT AD trusted. For example:

Well the good news is that with Workspace Access, there are a number of approaches which can be employed, so that from an end users perspective they can seamlessly access centralised Horizon applications with the click of a button. Even if those Horizon applications are linked to separate Active Directory domains.

The key premise of this capability, is that a user attribute must be shared across the AD domains. For example a users email address. The attribute you choose must uniquely identify the user.

This article details this capability via two approaches:

Both options can be used by the MSP simultaneously. For example:

• Agency 1 – Option B
• Agency 2 – Option B
• Agency 3 – Option A
• Agency 4 – Option B

The objective is to provide seamless access to centrally delivered Horizon applications for end users connected to each Agency.

The following video shows the end users experience, where the user clicks on a desktop shortcut to access a centralised Windows 10 desktop. Note that importantly, the user is not prompted for their userid or password.

The following sections detail how Option A and Option B are configured.

Option A

This option is available for Agencies who primarily have Workspace ONE Access (and Horizon) already deployed. Or the Agency may not utilise Active Directory Federation Services (ADFS). This option consists of the following components:

• Agency Access tenant (SaaS)
• Access Connector installed on-premises (setup with Directory Sync, Directory Auth, Kerberos and optional Horizon Apps)
• MSP Access tenant. Connector installed on-prem (setup with Directory Sync, Directory Auth, Kerberos and Horizon Apps)
• True SSO setup on MSP Horizon environment
• NO connection between Agency or MSP Active Directories (no trust)
• SAML Federation between Access tenants.

The architecture is as follows:

The Miro board is shown here

Setup Workspace ONE Access with Kerberos

For the Agency Access tenant, install a Workspace ONE Access Connector on a member server (not Active Directory Domain Controller). The Connector will be configured to provide Directory Sync, User Authentication (User Auth), Kerberos and Virtual Apps Sync (if Horizon is used).

Ensure that the local administrator is a domain administrator for the setup of Kerberos as part of the Connector installation, otherwise the script C:\Program Files\Workspace ONE Access\Support\scripts\setupKerberos needs to be run at a later stage.

A step by step guide in the setup of Kerberos with Access is detailed in this article by Carl Stalhood.

Check that Kerberos was activated by checking these logs:

C:\Program Files\Workspace ONE Access\KerberosAuthService-installer.log
C:\Program Files\Workspace ONE Access\Kerberos Auth Service\logs

The Kerberos Auth service should be listed with a status of Active and Health with a green tick.

Another excellent video on how Kerberos works as part of Access and it’s setup, is detailed in this video VMware Workspace ONE Access: Kerberos Authentication Service – Feature Walk-through by Peter Bjork (Principal Architect, VMware).

Once you have Kerberos setup, it’s important to configure your Web browser appropriately. See the following VMware documents on how to do this for Internet Explorer (+Edge), Firefox and Chrome.

To test, simply open your web browser and enter the URL of your Access tenant. If things are working correctly you should be logged into the Access portal without being prompted for a userid or password.

Setup True SSO on the MSP Access tenant

To setup True SSO on the MSP Access tenant, follow Carl Stalhood’s excellent step by step instructions in VMware Horizon True SSO with UAG SAML

Once True SSO setup, check that it’s all showing up as health in the Horizon console.

Even with everything showing as green ticks, my test users were still being prompted for their password. So I downloaded the True SSO Diagnostic Utility Fling to check everything was ok. You can run this command from your enrollment server.

If everything is shown with green ticks on the Horizon side, and TrueSSO has passed its Diagnostics tests, however your users are still prompted at the desktop for credentials. Next ensure that TrueSSO is enabled on Workspace ONE Access. If it is enabled it can be useful to perform a settings sync in the workspace one console (situations where TrueSSO had been disabled).

Within Workspace ONE Access, go to Resources – Virtual Apps Collections – Click the Horizon pod and click Edit – click on Pod and Federation – Click the Horizon Connection Server – ensure True SSO is enabled as shown:

Once I had enabled this in Access, True SSO working perfectly. You should be able to login to the MSP Access tenant (with SAML Authentication) and access a Horizon application without being prompted for a userid or password.

Federating two Workspace ONE Access Tenants

The step is to Federate two Access tenants together. This is detailed in this excellent article Using VMware Access to transform users between Active Directory domains by Ken Rowe (Senior Solution Engineer, VMware).

Ken details an example we have three Domains, Black, Blue and White. Users in Domain Black want to access resources in Domain Blue and White without being prompted for username or password.

For the scenario of an Agency and an MSP transpose the Ken’s example as follows:

• Agency = Domain Black
• MSP = Domain Blue

The flow of some of the tasks in Ken’s article are slightly different with the new Workspace ONE Access administration console. So I’ve updated some of the steps below with new screen captures.

Start by logging into the Agency Workspace ONE Access admin console. Navigate to Resources – Web Apps – Settings – SAML Metadata. Right click on Identity Provider (idP) metadata and choose Copy link address.

Now navigate to the MSP’s Workspace ONE Access tenant and add a SAML IDP. Enter an Identity Provider name and paste the Agency Identity Provider Metadata(URL) from the previous step. Click Process IdP Metadata.

In the Name ID Format drop down change this to: urn:oasis:names:tc:SAML:1.1:nameid:format:unspecified 

Name ID value = emails

In this example, we are relying on the Email attribute (@acme.com). Therefore, delete all the other Name ID Formats. For example:

Select the Users domain and Network IP range, in my case ALL_RANGES

You need to create an Authentication Method. We will use Password to login users into the MSP’s VMware Access tenant.

We named the Authentication Method, for example Agency1_PWD and password typically use SAMLContext: 

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.

For example:

Obviously your settings must match your implementation across all the Access tenants and in the AD records for the email attribute.

Right click on the SAML Metadata, Service Provider (SP) metadata link and choose Save link as…

Now you have downloaded a file called sp.xml. This will be used later.

Click Add

Now in the MSP VMware Access tenant you need to add the new Authentication Method in your access policy.

In this example we simply add it as the first one called Agency1_PWD. In our case we will only support idP initiated flow. If you are planning on supporting SP-init flow you must think about the order of authentication (authN) methods.

With these steps, we have now established a SAML based trust. The MSP’s Access tenant trusts SAML assertions from the Agency Access tenant.

Next step is to make sure you have user objects in both domains sharing the same attribute. We are using the Email attribute as the unique User Identifier. In my lab it is @eucau.com. This should be identical for the MSP and Agency Access tenant. My test accounts’ email address is [email protected], but note the Active Directory Principal name is [email protected] (for my lab)

Let’s now run a test to verify the SAML trust works from the Agency Access tenant to the MSP Access tenant. We need to create an application in the Agency Access tenant that represents the MSP Access tenant.

In the Agency Access tenant, create a new SAML 2.0 based Web Application called MSP Access Tenant (or suitable name)

Select URL/XML as per about in the picture below. Paste the content of the sp.xml file from the MSP Access tenant you saved previously into the Meta-data XML field and click on Save.

Importantly, modify the configuration to use Email instead of Username:

Name ID Format: Email address

Name ID Value: ${user.email}

Click Save.

Entitle your test user (in my case [email protected]) to the newly created application.

Now login to your Agency Access tenant. You should see an application icon to access the MSP’s Access Tenant as shown:

If you click on the MSP Access Tenant icon, you should be seamlessly logged into the MSP Access tenant and a suitable set if application icons displayed.

As Ken points out in his article, this method is not ideal from an end-user experience perspective. Users have to login to one portal and then click on an icon to launch another portal. Next, users must launch the application.

To solve this, Workspace ONE Access has a nice feature and that is that each resource has its own unique launch URL (deep link). This can be used in many ways. It can be used to create a shortcut in the Agency Access tenant to automatically launch the application in the MSP tenant. It can also be used for a desktop icon shortcut (shown in the video at the start of this article)

For Web applications the launch URL is easy to find. However for Horizon applications the URL needs to be constructed using the following URL format:

https://<hostname>/SAAS/API/1.0/GET/apps/launch/app/<resourceUUID&gt;

So for my Windows 10 desktop it would be:

https://msptenant.vmwareidentity.com.au/SAAS/API/1.0/GET/apps/launch/app/098cadcf-ca72-44b4-97de-6d69a12278aa

Create a new Web Application in your Agency MSP Access portal using the following example:

When you login to your Agency Access portal you as your test user account, you should see an application icon (which is actually available in the MSP portal)

You an also create a similar application icon on your Windows 10 desktops such as with Firefox:

Target: “C:\Crogram Files\Mozilla Firefox\firefox.exe” https://msptenant.vmwareidentity.com.au/SAAS/API/1.0/GET/apps/launch/app/098cadcf-ca72-44b4-97de-6d69a12278aa

Start in: “C:\Crogram Files\Mozilla Firefox\firefox.exe“

That way the user doesn’t even need to launch a web browser and select an application icon. They can quickly and easily launch the application from their Windows desktop at the click of a button! (as shown in the video above).

Summary

For Option A, we’ve setup our Agency Access tenant with Kerberos so the user doesn’t need to first login to that tenant. We’ve federated the Agency Access tenant with the MSP Access tenant.

For the MSP Access tenant, we setup True SSO so that even though the user is logging into the Access tenant using SAML, when they launch a Horizon application they are not prompted for their userid or password.

Finally, using a common attribute (in this case email address) the user can seamless access MSP hosted applications (Horizon or web) even though the Active Directories are not trusted in anyway.

Option B

This option is available for Agencies who have Active Directory Federation Services (ADFS) deployed and do not wish to deploy Workspace ONE Access. This option consists of the following components:

• Agency ADFS (on premises)
• MSP Access tenant (SaaS)
• Access Connector installed on-prem (setup with Directory Sync, Directory Auth, Kerberos and Horizon Apps)
• True SSO setup on MSP Horizon environment
• NO connection between Agency or MSP Active Directories (no trust)
• SAML Federation between MSP Access tenant and ADFS

The architecture is as follows:

The Miro board is shown here

Setting up ADFS

To install ADFS, you need a certificate. For my lab I went with a free letsencrypt certificate. I followed these two articles to first activate IIS and apply for a letsencrypt certificate.

It’s important to connect your IIS server to the Internet (NAT’ed and public DNS configured). For example in my case adfs.eucau.com.

Install Let’s Encrypt with IIS on Windows Server 2019

Next, follow these steps to get a certificate in PFX format.

Follow these steps to get a PFX file with Letsencrypt.

Then uninstall IIS, as it’s no longer needed for ADFS in Windows Server 2016 or higher.

Next add the Windows Active Directory Federation Services role to the server and then complete any configuration as required.

Completed the configuration and note the following:

I restarted my server. Since my Letsencrypt certificate didn’t support a hostname of certauth.adfs.eucau.com, I followed this article to ensure my firewall and DNS was setup appropriately for port 49443 (TCP) and public DNS name certauth.adfs.eucau.com.

Federating ADFS with Workspace ONE Access

There are a number of existing resources available to show you how to federate ADFS with Workspace ONE Access. Follow these instructions to federate the MSP Access tenant with an Agency ADFS environment.

These resources are listed below:

• VMware Workspace ONE Access: ADFS Integration – Feature Walk-through – video
• Integrating VMware Workspace ONE with Active Directory Federation Services – official documentation

One difference in my lab was that I needed to import the SP file from my MSP Access tenant instead of the URL method. It’s also important to get the ADFS claims rules completed correctly as detailed in this article. Particularly:

Specify the following settings. 

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "{AccessTenant}");

Where AccessTenant is the URL of your MSP access tenant. ie. mspaccess.vmwareidentity.com

It’s likely you’ll also need to change your ADFS tenant configuration so that a user can login with their email address instead of UPN. See – Configuring Alternate Login ID. You login to your ADFS server as administrator and run the following Powershell command:

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests yourADDNSdomainname.url

Where yourdomain.url is your AD domain DNS name.

Set your Access policies to use the appropriate ADFS authentication method as shown:

Since multiple Agencies will access this single Access tenant, you’ll need to configure appropriate network ranges within the MSP access tenant. That way, when a user from an Agencies private IP address range attempts to authenticate to the MSP Access tenant, the appropriate authentication method for that agency will be used. For example:

A fallback authentication method could be Password (cloud deployment) so that agency staff if they are away from the Agency network can still access MSP applications. They will then need to login with their userid/password.

Summary

For Option B, the Agency is already using Microsoft Active Directory Federation Services (or ADFS). The MSP Access tenant has been setup with True SSO so that even though the user is logging into the Access tenant using SAML, when they launch a Horizon application they are not prompted for their userid or password.

We’ve federated the MSP Access tenant with the Agency ADFS server.

Finally, using a common attribute (in this case email address) the user can seamless access MSP hosted applications (Horizon or web) even though the Active Directories are not trusted in anyway.

Synchronising Users between untrusted AD domains?

There are a number of options the MSP could employ so that user accounts are synchronised from the Agency AD domains to the centralised MSP AD domain. These could include one of the following Identity solutions:

Remember that only user accounts need to be synchronised from the Agency AD’s to the MSP AD. The above methods leverage two approaches so that even though the AD domains are not trusted from an AD perspective, the trust is performed between the Access tenants or via Access to ADFS.

OK, so that’s it! Any issues please feel free to reach out to me, or leave a comment!