Notes from the field: The broken VMware Access, UEM, and HUB portal

On a recent project with a customer, we encountered the issue that the VMware integration of the three products would be sort of “broken”. We first observed the issue after implementing the Intelligent Hub Verify rule set and see that this wouldn’t work. The devices and UEM wouldn’t show in the portal and the access policy would never apply. This in turn was caused by having the wrong OG configured in VMware Access, this was a weird issue because the entire setup was configured that way months earlier and was validated to work.

After resolving that issue, we encountered that the HUB services integration was missing functionality and not completely show the devices being integrated in the HUB portal. After a VMware GSS case with the necessary troubleshooting, we even encountered a P1 scenario that all devices wouldn’t have access anymore to the Intelligent HUB. This was eventually resolved by removing the configuration from Access in UEM and removing the WS1Hubclient OAUTH in Access, the final part was creating a new Built-in IDP for your domain in Access. According to support there are some cases that the IDP can get corrupted. The only solution is to create a new one and migrate the authentication methods over and then delete the corrupted one.

To summarize it, the problem occurred after the migration from 19.x release to 20.x release and higher, the Built-in IDP will get a new name with a migrated from name in it. This then was renamed to a normal name. The troubleshooting part introduced multiple faulty WS1Hubclient OAUTH modules which needed to be removed. The misaligned OG in Access is also to blame that the entire integration wasn’t working. After correcting all this the setup was instantly working again, there is no loss of data because the HUB services co-host within Access.

 

Hope it helps!

Notes from the field: VMware Access CRL url too long?

This is just a quick post regarding CRL checking in VMware Access. It seems that when you have the “NEW” UI interface enabled there is a bug when you put in a valid CRL location in the lengths of: http://this.ismycrlfilelocation.crl that it would chop the end off and stay at http://this.ismycrlfilelocation and then a faulty CRL location.

Solution is switching it over to the “OLD” UI interface and put the complete URL in and switch back.

It’s on support their backlog but it is known.

Hope it helps!

Notes from the lab: Using VMware Access as IdP for Citrix Gateway

I like to fiddle around with possibilities when it comes to SAML, OAUTH authentications. This all started when a customer engineer triggered me with the possibility of achieving an SSO experience with the Citrix NetScaler and using VMware Access as the source of truth for authentication.

Well guess what this works! And even for the native workspace app users as well. All with the conditional access policies of VMware Access before it.

First things first, I’m expecting that you know how to use the following and already have that in place:

  • Configured Citrix CVAD with Citrix Gateway doesn’t matter if it is Unified or not
  • Advanced authentication profile for SAML usage in Citrix Gateway
  • AAA setup to be used with the SAML / authentication profile
  • Working Citrix session policies set for web and native logins
  • VMware Access (Workspace ONE) on-premises or cloud variant

To start this sort of configuration, first you will need to download the VMware Access IdP SAML metadata or copy the URL of it and paste this in Citrix NetScaler:

The important part is that if you do not allow the NetScaler to have outgoing internet access it cannot validate the SAML metadata discovery, and everything will fail. In this case upload the IdP metadata as a certificate on the NetScaler and deselect the “Import Metadata” option the SAML Server action. Either way make sure that this is working for you.

Regarding the SAML Server action the “${user.userName}” value is the unique object in VMware Access which translates to either sAMAccountName or userPrincipalName according to your setup. With this value it will always work as expected with the logon.

When all the values are correct you can export the SAML metadata to be used in VMware Access as a new SaaS SAML 2.0 application. Paste the XML input in this app and assign the application to your test user/group. Make sure the application id and issuer name align between VMware Access and Citrix NetScaler.

To summarize above and a working setup:

  • Authentication Profile is mandatory otherwise you are not working with advanced authentication on Citrix Gateway
  • Citrix Gateway combines with a AAA for this feature
  • Make sure the URL’s match at both sides otherwise it will fail
  • Don’t forget the Relay State Rule in NetScaler for SAML security

Hope it helps! And if there are any questions give me a ping.

Notes from the field: The one that Android said no more local

On one of my projects, we’ve encountered a strange issue regarding domain name resolving.

A little background on the canvas painted it’s about a VMware Workspace ONE setup with working web URL’s and UEM enrollments, you name it. We have a nice setup regarding managed devices and these use a per-app VMware tunnel connection to achieve secure application access. All working dandy fine. The devices are based on a Ascom Myco 3 setup with Android 10 and are dedicated used for specific applications.

Then we moved on to the managed devices in a COPE / Work managed format for the normal usage of applications work and personal usage. We also implemented VMware tunnel in a per-app situation and we got some mixed scenario’s as in working, not working or not resolving at all the URL’s with a .local suffix (I know what you are thinking .local isn’t best practice to use etc. etc. well we don’t live in a perfect world and there are a LOT of companies with .local suffixes over here) on Android 11/12, it more of less pointed to Android 12 that changed DNS resolving with mDNS support as in the way how it always should have been, see Android adds mDNS support so .local hostnames finally work (esper.io) for the details.

We had some interaction with VMware support as we first thought that it would be a combination issue with VMware Tunnel because the behavior in a Workspace ONE Web with the built-in tunnel SDK would work just fine. But as soon as we changed the URL’s to a not .local suffix but .net or something else it would instantly work.

On a closing note, I think more and more customers will see this change now that Android 13 is on its way. It’s good to prepare in advance.

Special thanks to my partner in crime on this case, Sidney Laan.

See the following reference articles and blogs for some fun reading and a hint to a new DNS setup:

Local DNS resolution suddenly stopped working… – Google Pixel Community

Why do Android 12, 12L, 13 Preview devices don’t resolve local DNS anymore? – Stack Overflow

Active Directory: Best Practices for Internal Domain and Network Names – TechNet Articles – United States (English) – TechNet Wiki (microsoft.com)

Hope it helps!

Notes from the lab: Citrix ShareFile and VMware Access SSO

When configuring Citrix ShareFile for an SSO experience with your Microsoft Active Directory setup we have the following guides to use it from Citrix. See How to Configure Single Sign-On (SSO) for ShareFile (citrix.com)

Well I’m having my setup with another Identity Provider in my own lab and still want to achieve an managed SSO setup from my end. To get this to work I checked the setup from an existing integration setup like Microsoft ADFS and reverse engineered it to VMware Access instead.

The following will give you an working SSO setup with VMware Access as your Identity Provider for Citrix ShareFile:

First configure the basic settings of Citrix ShareFile with your URL’s

https://tenant-fqdn-sharefile/saml

https://tenant-fqdn-vmware

Copy paste the certificate information from your VMware Access tenant

Create the application in VMware Access

Use the explicit logon URL of your application in VMware Access in Citrix ShareFile

Use the https://tenant-fqdn-sharefile/saml/acs in VMware Access for consumption

After this make sure that an user from your corporate identity is synchronized in Citrix ShareFile and both of them match so that SSO can be achieved. Afterwards you can nicely click the icon in VMware Access from IDP point of view:

Or you can login via the SP side from the Citrix ShareFile browser landing page:

Hope it helps!

Notes from the lab: VMware UAG content gateway and an A+ rating

In addition to Jesper Alberts his blog a follow up with another custom UAG edge service which has it quirks called the content gateway. For the SEG article see vJAL.nl – Secure Email Gateway

Now diving in, when you configure the edge service you have the following options to configure Custom Values for Content Gateway and bare in mind that you’ll find this article after your first check on SSL Labs because an disappointing rating is what you get out of the box. See below screenshots for an A+ rating on SSL Labs:

After configuring these options you need to re-save/update the configuration in the UAG as well otherwise the service will not get these changes. And voila an A+

Hope it helps!

Notes from the field: VMware Access Kerberos integration and Office 365

Okay let’s say you have your setup for VMware Access nicely configured with your directory search attribute configured as userPrincipalName because that’s the modern way with all cloud services etc. and configured your inbound Kerberos authentication through the IDP of the Access connector. Everyone is happy and all is working well with external connections, internal connections, mobile connections and what other type of connections we can think of. Then comes the day Office 365 is going to be integrated and still all is working well externally, mobile as well and then you get some calls regarding users who get a prompt unknown user when accessing the portal through Kerberos logon. You get to the trusty old log view and dig in and see message unknown user entries with the UPN value of your internal domain. Well, turns out that when the search attribute is selected as UPN you cannot switch over to your routable domain which is being used in Office 365 and still expect a working Kerberos logon. The only way this little beauty is going to work if is the search attribute is sAMAccountName. After a GSS support case got this one confirmed this is the only way that will work, or you would need to add a global catalog specifically for the domain in question which means double accounts, dedicated domain controller etc. etc. no one wants that!

To summarize sAMAccountName is the value which will work with almost everything, keep in mind that VMware Access is an IDP so we have the values and can transform it to any other solution as we want but specifically in this case the internal Kerberos and VMware Access have a fitty when it’s userPrincipalName. I did test out two different solutions which also worked and that is using internal certificates to be used as an authentication policy, so you add the ADCS setup as a trusted KDC in VMware Access and then will get your SSO that way or integrate ADFS as an IDP and access policy because then you use the Kerberos flow through ADFS.

To give the users still a nice e-mail-based logon experience add group filters to the access policy and that in turn introduces the user sign-in unique identifier experience which you can set to email.

See the following articles for some reference regarding Kerberos:

VMware Workspace ONE Access: Kerberos Authentication Service – Feature Walk-through

Adding Kerberos Authentication Support to Your VMware Identity Manager Connector Deployment

Managing User Attributes in Workspace ONE Access

Hope it helps!

Notes from the field: VMware Workspace ONE UEM and Android Zero Touch

On a recent project we were implementing Android Zero Touch for out of the box enrollment through WS1 UEM. For a detailed explanation what Android Zero Touch is take a look at the following URL: Zero-touch enrollment for IT admins – Android Enterprise Help

When the Zero Touch Portal is enabled through the reseller and you have your access the DPC part of UEM or any other supported EMM vendor can be added and assigned. For WS1 UEM we have the following options for configuration: Enroll Android Device Using Zero Touch Portal

Now comes the part that was the “issue” or better said somewhat misinterpreted throughout the documentation. When you configured the setup through above steps you will always get a prompt after the DPC part through VMware Access that you need to login, but the whole purpose is that there is an auto-enrollment throughout Android Zero Touch and it’s DPC values through WS1 UEM and Access. Well the latter is the blocking part.

If the authentication of WS1 UEM / WS1 Access is configured to use the source of authentication from HUB services as WS1 Access you will break the staging user part from Androids perspective. Apple for example does not have this issue when using DEP/VPP because the staging works different through that program integration with WS1 UEM.

Flipping the authentication over to UEM as primarily source and everything is working nicely. But we don’t want this because Access should be the source of authentication regarding every nicely integration for web applications throughout SAML, other IDP providers etc. etc.

Logged a support case for this but didn’t get any satisfying results regarding the enrollment process. I’ll get back to this because support did help me after we got that one fixed with something else.

Just by luck an internal colleague has a nifty RSS feed active for useful blogs and this one popped up and immediate had my interest: Automated no credential enrollment when using Workspace ONE Access for source of Authentication

OK! That explains a lot after reading and there is another VMware URL regarding extra DPC values for UEM specific items: Additional Supported Enrollment Flags for Android Enrollment and the simple addition of “useUEMAuthentication” did the trick. This effectively disables Access for the enrollment part and allows the use of a staging user again.

Well staging works and… bummer the HUB screen keeps refreshing and we can’t sign in as the owner of the device. And here we come back to VMware support, after some testing I flipped over the staging user account in UEM from “Standard – Users are asked to log in after staging” to “Advanced – Enroll on behalf of another user” and the latter gives the experience that you assign the user after staging and then login and presto no more spinning HUB screen and it works.

After discussing this with support it’s the way that how Zero Touch enrollment works the staging user account needs to be set to advanced, the standard mode isn’t supported in this way of enrolling. And after that case closed!

Hope it helps!

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 Access Roles and RBAC bug

On recent projects we where configuring RBAC roles in VMware Access Cloud and stumbled across something annoying which turned out to be a bug. The issue is that when you assign the RBAC roles through super admin, read only admin and directory admin that once added you can’t delete or re-add the same group, it will error out with the following error:


It also isn’t possible to unassing the role anymore, and you might think okay well the role still works! Well no it doesn’t the role is hardcoded and can’t be removed anymore:
Deleting the complete directory and re-adding the directory doesn’t solve it either it will come back no matter what. Logged a GSS support case for this and it turns out this is indeed a bug.

If you have the same log a case and reference HW-123910 so it can get some more traction.

Hope it helps!