Notes from the field: VMware UAG and Citrix ADC scenario’s

On a recent project we were testing some scenario’s for the usage of VMware Blast BEAT through Citrix ADC. For some more information regarding Blast see the following article: VMware Blast Extreme Optimization Guide | VMware

Normally you would see that the Citrix ADC setup is an SSL-BRIDGE vserver with accompanying UDP vserver on the same IP for the ports 443 and 8443 which are the default for BLAST and BEAT usage.

There would be situations that port 8443 cannot be used regarding company compliance or restraints that only port 443 is allowed to be used. In this case you would need to change to an SSL-Offloading setup because we can’t intercept any traffic in a SSL-BRIDGE scenario or apply WebSocket usage in a profile.

We need to create an HTTP profile which enables WebSocket connections and we can use on the new SSL-Offloading vservers

Afterwards bind this profile to the SSL-Offloading vservers

Then we need to change the service group which we use in the UDP vserver to 8443, so the frontend is 443 and the backend is 8443

Lastly the changes on the UAG need to be reflected that the firewall connections would also be 443 for TCP/UDP usage and shared services. See the following articles for more information regarding firewall port requirements and alternate setups in the UAG: Firewall Rules for DMZ-Based Unified Access Gateway Appliances (vmware.com) and Blast TCP and UDP External URL Configuration Options (vmware.com)

With this setup you can service everything for the users on port 443. Do keep in mind that port sharing in this way is an excessive CPU load which can seriously impact the setup. See the following article for some clarification: Unified Access Gateway (UAG) high CPU utilization : HTTP 503 error (78419) (vmware.com)

Hope it helps!

Notes from the field: VMware Horizon sessions disconnecting after syslog changes on UAG

On a recent project where we have VMware Horizon 7.13 and UAG 20.09 appliances for the external connections some strange behavior was observed when putting in the syslog URL entries.

After adding or removing entries here and saving the settings all the connections through the UAG will get terminated. Finding this behavior strange as to you don’t do anything that special so why disconnect these sessions.

Had some discussion on the vExpert slack channel and quickly came to light that it looks like an regression issue.

The following article describes the issue User sessions are disconnected through VMware Unified Access Gateway when the configuration settings are changed with the UAG Admin UI (56487) and this should be resolved in later versions.

The version tested here is the release that accompanies Horizon 7.13 build and that is UAG 20.09.

The versions tested by Jesper Alberts were Horizon 2012 with UAG 20.09 and the same problem.

The versions tested by Stephen Jesse were Horizon 7.10 with UAG 3.7 and 3.10 without any issues.

So to sum it up if you have the builds in question it might be a good action to log a support case.

Hope it helps!

Notes from the lab: Microsoft ADFS and VMware UAG

You don’t see many configuration articles around ADFS and UAG and that’s why I would like to share my setup.

First things first, I’m expecting that there is an working Horizon environment with True SSO enabled for access to the desktop. And a working ADFS environment to add a new application to test with.

My setup:
1 x ADFS for internal usage
1 x WAP for external usage
1 x UAG v3.10 – dedicated for ADFS with its own URL
1 x UAG v3.10 – dedicated for WS1 with its own URL
2 x Horizon Connection Servers
2 x Horizon Enrollment Servers

The following articles helped me in setting this up:
https://docs.vmware.com/en/Unified-Access-Gateway/3.10/com.vmware.uag-310-deploy-config.doc/GUID-E4C8B88F-C771-4829-ABBE-12F7FBF517C3.html
https://communities.vmware.com/thread/625006
https://thevirtualhorizon.com/2019/12/14/integrating-microsoft-azure-mfa-with-vmware-unified-access-gateway-3-8/
https://techzone.vmware.com/enabling-saml-20-authentication-horizon-unified-access-gateway-and-okta-vmware-horizon-operational

Setting this up starts with downloading the “/FederationMetadata/2007-06/FederationMetadata.xml” file of your ADFS setup and saving this on your configuration machine

Now go to the UAG admin appliance on the management port https://xxx:9443 and scroll down to the Identity Bridging Settings, select the gear icon of “Upload Identity Provider Metadata” and in the next screen press on the select link where you can upload the metadata file of ADFS.
Now go to the Horizon settings on the top and select the gearbox and in the next screen select more to show the auth methods to be used. For True SSO select SAML. Next select the uploaded Identity Provider which is now visible and click on the “Download SAML service provider metadata”. Save everything and close the admin portal.

Next in ADFS configure a new “Relying Party Trust” claims aware application and import the downloaded SAML service provider metadata file from UAG
When completed edit the “Claim issuance policy” for the application and create a rule with attribute store active directory selected and provide the input for “User-Principal-Name” with “Name ID” as outgoing claim type.
Edit the application and select encryption and click on remove the encryption certificate. This enabled will not give an valid SAML assertion or logon.

This is all that is needed in ADFS, the application can be assigned anyway you want. The last steps are in Horizon itself.

Go to the admin panel of the connection server and configure an SAML 2.0 Authenticator, create one and name it accordingly (don’t forget to enable True SSO on this connector) and make sure it is an static type. Copy paste the federationmetadata.xml content into the SAML Metadata screen and click OK.

Set the delegation of authentication to VMware Horizon (SAML 2.0 Authenticator) to optional or required. The latter prohibits passthrough authentication straight from the servers itself and will always require a SAML assertion.

This is it, afterwards you should see an ADFS logon possible with SSO in place.

Some extra information for any use case with ADFS/Workspace ONE combined then this procedure will not help. For Workspace ONE integration the only working and supported way is to configure VMware Horizon with VMware Access. I’ve tried it configured with VMware Access and the same UAG and you will get an access denied because the SAML configuration is in place at the Horizon Connection Servers instead of the UAG. ADFS can also be integrated with VMware Access and the SSO can be achieved in that way which is a route you would take when using Workspace ONE.

Hope it helps!

Notes from the field: VMware UAG reverse proxy why doesn’t it work!

When configuring VMware UAG as an reverse proxy I’ve encountered some issues last year that as far as I could see wasn’t all to well documented. My reference article for the configuration was the following: https://techzone.vmware.com/configuring-web-reverse-proxy-identity-bridging-vmware-unified-access-gateway-vmware-workspace-one-operational-tutorial#985671

Basically when you follow it to the letter in your test deployment and with a test site you will not have a working reverse proxy URL. At the time when I encountered this I’ve logged a GSS support case and in the troubleshooting process it was clear that the proxy pattern set wasn’t working whatsoever, the correct one should be (|/(.*)|) instead of (|/intranet(.*)|)

My understanding was that if you would configure the instance id and configured the proxy pattern accordingly it would work but that wasn’t the case. Only when not referencing it and just passing it through it began to work.

When configuring multiple reverse proxy URL’s be sure to create corresponding proxy host patterns on the instance id’s

See the following screenshots for a working reference when using UAG as a reverse proxy for Exchange 2019 and Citrix StoreFront 1912

Hope it helps!