A customer of mine had an interesting request. They would like their end users to have access to published RDSH Horizon Apps from 2 different Horizon Pods in 2 different forest domains from the same Workspace One Access portal.
The first scenario I came up with was to integrate two different Horizon PODs with the same Workspace One Access tenant using a Workspace One Access connector for each pod. This would present to the end users 2 different domains for them to login in Workspace One Access.
But this is not quite what they were asking for. The wanted the user to be able to access applications from the 2 different PODs from the same portal using the same domain credentials.
At first thought I did not think that was possible but then I realized the Horizon Apps entitlements are set up in the Horizon POD and not in Workspace One Access. The next step then would be to investigate how a user from one domain can access Horizon Apps published in another domain. Looking further into this I confirmed that as long as a two-way Forest Level Transitive Trusts exist between domains in different forests a user from domain A could be entitled to an Horizon App on Domain B and the Horizon Enrollment Server could be set up to provide SSO in order for the user not to have to re-type his / her domain credentials once the Horizon App session was established.
Horizon Domain and Trust Relationships
Enrollment Server Architecture
In summary the topology required for this specific scenario would be similar to this:
The first thing I did was to confirm I had two-way Forest Level Transitive Trusts between my domains, which I had already set up for previous testing scenarios.
Once I confirmed the domains trusts were there I then set out to add the two Horizon Virtual App Collections (PODs) into the same Workspace One Access tenant. Before adding the Virtual App Collections, I had to register Workspace One Access Connectors within my Workspace One Access tenant. Each connector had access to one specific Virtual App Collection (POD)
After that I decided which POD would be entitled to visiting users from other domains and then added their user accounts to the entitlement list of the RDSH App in question. In my test scenario users from the lvalente domain would have access to Apps on the Horizon POD deployed on the lvalente domain and also access to Apps on the Horizon POD deployed on the lgranado domain.
At this point the last component missing was the Horizon Enrollment server in order to create the user certificates required for TrueSSO. In my test scenario the connection server on the lgranado domain would connect to an enrollment server on the lvalente domain in order to have a lvalente domain user authenticated. The enrollment server installation is an option on the Horizon Connection Server installer. You just need to pick the enrollment server option and install it on a member server of the domain in question. In my test scenario the domain was lvalente.local.
Since the user certificate was issued by a CA other than the lgranado domain (the lvalente domain CA), I had to add the lvalente root certificate to the Trusted Root Certificate Authorities folder on the computer certificate stores of the lgranado.com domain controller and Connection server.
I also added the lvalente CA root certificate to the lgranado default domain policy so all the machines in the lgranado domain would have the root certificate added to their certificate store.
Before installing the Horizon Enrollment server, you need to create the certificate templates required by the enrollment server. The steps to create those templates can be found here: Article
Once created the certificate templates and installed my Horizon Enrollment server on the lvalente domain now I had to register it on the lgranado POD connection server in order for the lgranado POD connection server to be able to request user certificates for lvalente domain users trying to authenticate. The list of commands I used can be found here
Once I completed the vdmUtil commands I logged in the lgranado POD connection server admin console and confirmed the enrollment server status was OK.
Time to test, after all the proof is the pudding as they say.
During my initial tests I was getting an error on the enrollment server informing it was receiving a request from a specific certificate (the connection server certificate) but that certificate was not trusted. I cleared this error by confirming that my connection server self signed cert was located in the enrollment server computer certificate store on both VMware Horizon View Enrollment Server Trusted Roots and Trusted Root Certificate Authorities folders. The Connection server self signed cert is located in the connection server computer certificate store in VMware Horizon View Certificates folder. This is related to the “Export the Enrollment Service Client Certificate” and “Import the Enrollment Service Client Certificate” sections of the enrollment server installation guide.
Once I cleared that error and continued with my testing, I was constantly getting this one last error when trying to open app on lgranado.com POD from Workspace One Access using an lvalente.local domain user, and this one took me a while to figure out. The Enrollment server was issuing the Certificate properly for the Horizon session, but Windows was not accepting the certificate.
Eventually I found a Microsoft article regarding third party smart card authentication informing the smart card provider CA root certificate must be added to the domain. Article. The article provided two methods. Using the Certutil command or use the Enterprise PKI MMC on the domain controller. I used the latter to add the lvalente.local Root CA certificate to the lgranado.com domain NTAuthCertificates tab.
