Notes from the field: VMware Access with VMware UAG and JWT validation

It’s been a while since I’ve retested the setup with validating gateway request with JWT entries, because I thought it was depending on an appliance such as F5 for it to work. See Launching Horizon Resources Through Validating Gateways (vmware.com)

I did try and configure it none the less but never got it farther then just enabling JWT in Access with no audience enabled and the UAG also not configured with any WS1 for a working desktop, otherwise it would always error out with something like below:

Well that was then and this is now and here comes a very nice blog post by Nick Burton explaining how easy it is and just works. See Integrating Workspace ONE Access and UAG with JWT – Nick’s IT Blog (nicksitblog.com)

Ok, mind blown and Nick and I got to some trial and error testing and checking the setup of the environments is different whatsoever. Everything seems to be in order.

This is the URL where you can check it btw:

https://<WS1 AccessURL>/SAAS/API/1.0/REST/auth/token?attribute=publicKey&format=pem

So digging in deeper and putting the UAG in DEBUG mode and reproducing the issue gave some interesting feedback in the JWT section of the UAG:

08/03 19:10:01,061[nioEventLoopGroup-10-1]INFO  jwt.JWTArtifactHelper[validateJWT: 215][192.168.30.254][][Horizon][287c-***-dd51-***-7f3c-***-f651]: JWT rejected with error message : Unable to process JOSE object (cause: org.jose4j.lang.InvalidKeyException: An RSA key of size 2048 bits or larger MUST be used with the all JOSE RSA algorithms (given key was only 1024 bits).): JsonWebSignature{“typ”:”JWT”,”alg”:”RS256″,”kid”:”1624905951″}->eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjE2MjQ5MDU5NTEifQ.eyJqdGkiOiI0M2RkOGY3OS1kNTc5LTRmMTEtYjI5Yi00M2Y4ZTY1NTEwNDAiLCJpc3MiOiJodHRwczovL3RlY2huaWNhbGZlbGxvdy1jb25zdWx0YW5jeS52bXdhcmVpZGVudGl0eS5kZS9TQUFTL2F1dGgiLCJhdWQiOlsiaHR0cHM6Ly91YWcudGVjaG5pY2FsZmVsbG93Lm5sIl0sImFydGlmYWN0IjoiQUFRQUFIVFJLZjJBTVFpMzJNNGxLOVRUMkFNUmRqdmhKVEdMTmErVDhzQVIxeW5DSndSalZFVlk3VlU9IiwidXBuIjoiaGhlcmVzQHRlY2huaWNhbGZlbGxvdy5jb20iLCJleHAiOjE2MjgwMTgwOTgsImlhdCI6MTYyODAxNzc5OH0.ffFHm8zqNyfNJGFl_-at_NL_gEa9PzC88iIBW23jdaOsdXJAOZu6gVD-eiMxWLpX_i9Hje2v6FhqDvetv_M1uutaPgCAZU34-QxmWLN2XK4MT0IaQdLK

It seems that the key size of the tenant is 1024 and 2048 is expected to use this.

So validating tenants again and Nick has a fairly new tenant in which I have an older tenant. I’ve used a separate tenant which is also new and presto it works out of the box there as well. Key size is 2048 and all is fine.

So with this information logged a GSS support case for this and turns out it’s indeed the case that new tenants will get a key size of 2048 and older tenants still have 1024. At this time there is no ETA on when older tenants will get upgraded. If you also want to log a support case and get some more traction reference HW-106923

Hope it helps!

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: Bye Bye VMware View Composer

I was upgrading my lab to VMware Horizon 2012 and yes shame on me I still had an composer in my setup. It was already mentioned that VMware Composer is deprecated from the 2006 release but now in 2012 it will block your upgrade when you still have it enabled. Only after disabling composer on your vcenter the upgrade will succeed and afterwards composer will be gone as an configuration item.

See the following screenshots for detailed information:

Notes from the field: VMware Horizon Instant Clone and Imprivata OneSign

On a recent project consisting of an VMware Horizon instant clone setup and Imprivata OneSign in the desktop for SSO capabilities I’ve encountered some strange timing issues.

Normal logins through the horizon client via connection server would be ok with the OneSign agent online, logins through the UAG without TrueSSO would also be okay. (so it seemed)

TrueSSO enabled because the total solution is a Workspace ONE deployment and we want to use one login of course regarding credentials introduced a problem. The login process would work just fine but the agent of Imprivata would stay offline only to be online after a reconnect to the desktop.

A long troubleshooting process started with the team and also a support case opened with Imprivata pointed us in the direction that there was an issue all along with the base setup as well.

Logging in to the VMware console of an desktop without the UAG or TrueSSO in place would provide the same result, an offline OneSign agent and the second logon or disconnect/reconnect even in the console would resolve it.

Long story short after that finding we did an test to restart the OneSign agent before logon of any user (tested this through Ivanti AM) and then let the user logon and presto no more issue.

We then created a script to be used in ClonePrep so that we don’t have to rely on Ivanti AM and after that issue is also resolved.

But now comes the kicker. The solution at the time was an Horizon 7.10.x ESB release and for customer requirements and lifecycle management to be future ready we needed to go to the 7.13 release of Horizon (not perfectly documented but this is the new ESB release as well and last significant release of Horizon 7)

After this update to the connection servers the ClonePrep scripts would time-out and not function correctly anymore. Removing that from the pool did blow my mind because after that the complete issue was gone and the OneSign agent would be online all the time no matter what.

Tested this with an old image and the 7.10.x release of Horizon installed with the 7.13 connection server as backend and indeed no more issues and everything fine. The root cause seems to be “something” in instant clones that got fixed/changed in 7.13

To summarize, the fix for an 7.10.x release is to use any means of restarting the OneSign service before any user will logon and for the 7.13 release it’s no issue at all. (I’m betting this will also be the case for Horizon 8 but haven’t tested that with Imprivata)

Some reference articles:
The Imprivata URL’s you will need an active account at Imprivata to view them

How to enable Imprivata Agent trace

Does Imprivata support VmWare Instant Clone for VM Desktops?

Configuring Kerberos Authentication (imprivata.com)

Configuring Support for VMware True SSO (imprivata.com)

Information on Horizon 7 Extended Service Branch (ESB) (52845) (vmware.com)

VMware Horizon 7 version 7.13 Support Plan (81189)

ClonePrep Guest Customization (vmware.com)

Notes from the field: VMware Horizon Enrollment Server and Core O/S

Recently had an deployment with a customer who has a mandate core o/s deployments are preferred unless the product doesn’t support a core o/s installation.

Well for this deployment we created two core o/s subordinate ADCS servers with the enrollment server software installed and configured. Everything is working fine and dandy, no issues and seems like its golden for production deployment.

Guess again.. all the Horizon products aren’t supported for a core o/s installation, yes it will work most of the time but if you’ll find any errors or in need of GSS support then most likely you would need to install a GUI variant. I’ve had two support cases open and both of them state it’s not supported even though the documentation isn’t explicitly stating that.

Take a look at https://docs.vmware.com/en/VMware-Horizon-7/7.10/horizon-installation/GUID-30AA88CF-8CDF-42E5-97D4-D75B2171434B.html for the ESB release and https://kb.vmware.com/s/article/78652 for the Horizon 8 2006 release.

I’ve asked for a documentation update in the support case and also left feedback that the articles need updating. Please do the same so that we can prevent others from installing a unsupported setup.

Hope it helps!

Notes from the lab: VMware Horizon and Microsoft MFA NPS Extension

In my own lab environment I have a mixture of EUC components and dual factor configured accordingly, but more and more I see that customers also just use the MFA solution of Microsoft to integrate it for their environments. Why not it’s included with your license right.

So back to the techie part I’ve configured my own NPS setup on a Windows Server 2019 and configured the RADIUS setup. Installed the MFA NPS extension and had a pre-existing configuration for my Citrix ADC appliance.

I’ve configured my Horizon connection server as an RADIUS client and enabled the configuration request and network policies for it as well, configuration type NAS IPv4 Address and the IP-address of the server.

Afterwards put in the configuration part in Horizon itself pointing the RADIUS authentication to the NPS server with all the necessary fields and/or additions that you want.

Well basically all should be working instantly when logging on to the Horizon URL or client.

I did however had some issues when logging in and stuff would time-out, event entries would say that the wrong dual factor request was given. This ultimately came from the fact I didn’t have a primary authentication set in MFA, I’ve checked that I could use my yubikey, SMS or push authentication. The resolution for this was to select primary push in the authenticator app and then it worked instantly.

Reference articles:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension
https://christiaanbrinkhoff.com/2017/02/17/how-to-configure-azure-mfa-for-citrix-netscaler-gateway-radius-by-using-the-new-nps-extension/

(off topic there is an issue with 2019-NPS which I’ve encountered when configuring RADIUS-WIFI authentication, see the resolution here: https://community.ui.com/questions/FYI-Windows-Server-2019-NPS-for-RADIUS-broken-w-fix/364c7c17-b3d3-4973-8dd2-e4e701309300)