Something that has been in the works for quite awhile is bringing the Tunnel to a full BYOD presence in the enterprise. The idea is pretty simple. App-Level Management is pretty sexy isn’t it? Users are super privacy-focused and Unified Endpoint Management needs to learn to shift to these growing needs. VMware has done this already for Boxer and Workspace ONE Web to combat the whole “Good” use case. Logically it’s super simple. You let people enroll their device at the device-level and that’s it!
Now, VMware is bringing App-Level Management (ALM) to the Workspace ONE Tunnel, which makes a ton of sense since the UAG Proxy is sunsetted and you need a solution to deliver a BYOD work browser. Today, we will discuss how this functionality is now available for MacOS and Windows 10. We’ll be focusing on MacOS as its significantly more interesting. We’re going to cover how you setup Workspace ONE to support the standalone WS1 Tunnel, the WS1 Tunnel enrollment, interesting troubleshooting tidbits, and my thoughts on the platform/idea moving forward.
Setting up the Workspace ONE Tunnel for Standalone Mode in the Console
Before we get too crazy, let’s check out a short video, which will cover two main items, which we will discuss afterwards.
We don’t really need to touch on the first path with the exception is the language doesn’t mention Tunnel so don’t sweat that too much:
We should discuss building DTRs (Device Traffic Rules) for Standalone because I feel people aren’t going to get it right.
Strategy around WS1 Standalone Mode Tunneling
I think we should talk. I mean seriously…
The ENTIRE point of offering a solution like this means you are trying to make people’s lives better. So with that in mind, we need to re-evaluate how we deliver DTRs in this mode. DO NOT USE THE SAME DTR FOR THE LOVE OF GOD!
One variance from the video to update everyone on. You must use a FULL Device Tunnel profile for MacOS as that is all that is supported:
The key here is that if you don’t need to enforce the WS1 Tunnel for your offering then use BYPASS. It’s crucial that we make people actually want to USE it. I know I’m using a ton of caps here, but it’s crucial to explain. DO. NOT. MAKE. PEOPLE’S. LIVES. HARDER.
**Coming Soon (Needs Per Application Tunnel) ** So my initial use case will be Standalone WS1 Tunnel is secure Microsoft Edge with App Protection Policies and straight deliver a tunneled-Edge app with WS1 Tunnel, which achieves your goals. Secures the container, gives people access, and let’s them keep their privacy. Conceptually it’s really not that complicated people. Let’s build products and offerings that people actually want to use.
As promised here is the code for deploying Edge:
Package ID: com.microsoft.edgemac
Designated Requirement: identifier "com.microsoft.edgemac" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UBF8T346G9
So in closing, use a new Tunnel rule that ACTUALLY balances security and usability. Let’s do good adulting folks.
Enrolling the Workspace ONE Tunnel Standalone Client for MacOS
I decided to pick a single platform for demo purposes (as opposed to porpoises). MacOS is a good example for a few reasons:
- MacOS does a full device VPN so it provides stronger context.
- The setup/install is busier and let’s you see the initial user experience more in-depth.
- I expect it will be a stronger use case for BYOD as MacOS BYOD has been banging down a ton of doors recently.
Overall, you saw that the privacy story is really great. They provide pop-ups asking for system extension approval and creation of the proxy connections to name a few of those items. I would say that in general the experience isn’t too bad. In the next section, we will cover some of the “things” I ran into setting things up.
An Interesting Troubleshooting Issue I Found
One item that I expect is going to trip up a ton of people is the authentication context and how it trickles down.
When I enrolled, I kept running into this:
Let’s quickly unwrap what I found, which provides some insight into my troubleshooting process.
So what does “Failed to lookup subscription to resource” actually mean?
I went into the Audit Events and looked at the bad actor:
At the bottom of that failed event, it gives you a fun little message: “failureMessage” : “App launch failed for subscription id: 509b3483-5ca5-439c-a9f7-ddad173b3be0 and tenant id SYNTEREX.”
So the Subscription ID is actually the Application ID inside of the WS1 Access Catalog. Another interesting tidbit you will notice below that line is it made me do Hub MFA. So I said WTF? I don’t do MFA for enrollments this is nonsense.
Well, much to my surprise look at the AirWatch app, which is literally never used (its technically used for stuff like SSP but no one really uses it):
As a FYI, those images have zoom in them so you don’t think I’m batshit crazy. Basically, I learned that the WS1 Tunnel Standalone enrollment doesn’t use the default policy. So you will want to move the AirWatch app to your default policy to keep things simple and limit stress.
UPDATE: A few known issues that I have identified are:
- Client Authentication certificates are not currently supported
- You cannot change Tunnel Profiles mid-stream. It requires you to delete the device in Workspace ONE, unenroll on the device, and re-enroll.
Some Thoughts on WS1 Tunnel Standalone Mode
Overall, WS1 Tunnel Standalone Mode is something many of us have been waiting for a long time. My main callout is they need to deliver an easier way of getting the application. Today, we will be expecting users to rely on administrators to get started. I think simply a getwsonetunnel.com should be done. (In fact I bought the domain today, so if you want to listen to me Martin, I’ll hand it over).
As someone who has significant experience in App-Level management, I would suggest having a disclaimer explaining why system extensions/proxy settings are needed by the Tunnel similar to how VMware did the privacy app on mobile. A few of these small nuances would make the product become infinitely better.
Lastly, please please BRING this to iOS and Android quickly. Sometimes we lose steam on a great new offering because the user expectation isn’t there yet. This would crush on Android for those shops that don’t feel comfortable going full device management on Android. This is a nice way to provide something similar to what they have with Boxer today.
