Tunnel 2.0 for Windows and DFS-Namespaces

Hello, it’s Pim here again,

It’s been a couple of months since I created this blogpost on the VMware Tunnel: https://brookspeppin.com/2020/01/23/how-to-setup-the-new-workspace-one-tunnel-windows-desktop-application/

This blogpost was well received and started some good discussions. Since that blogpost the VMware Digital Workspace Tech Zone site has also published a detailed guide on how to deploy the VMware Tunnel on different platforms:
https://techzone.vmware.com/deploying-vmware-workspace-one-tunnel-vmware-workspace-one-operational-tutorial

Apparently, lots of customers are using VMware Tunnel. So, it’s good to see development has been busy and released a new 2.0 version of Tunnel for Windows. On top of that I received questions from many customers how they could access DFS-Namespace shares through the Tunnel. My colleagues from engineering did a great job in helping me figure out the correct configuration to make this possible. This was enough justification to come up with a new blogpost.

Let’s start with looking at the new 2.0 release and the added features; Tunnel 2.0 for Windows now offers support for applications that leverages UDP. An example of such an application is Skype, but there are other apps that benefit from this change, like DFS namespaces.

Last week, a minor version 2.0.2 has been released that includes the following fixes:

• S/MIME encryption in Outlook is slow.
• Improvements to DNS handling in split-DNS scenarios.

All the Tunnel releases, documentation and release notes can be found here:
https://my.workspaceone.com/products/Workspace-ONE-Tunnel

And details on the latest 2.0.2 release can be found here:
https://kb.vmware.com/s/article/80228?lang=en_US

The second topic of this blogpost is the main reason I’m writing here: DFS support.
Many customers that try the new Tunnel really like the support for file shares, but they quickly discover that DFS-Namespaces don’t seem to work. This is mainly because DFS relies heavily on DNS and the DFS protocol sends shortname references. To solve this we need to make sure the proper DNS search domain is added to the DNS queries that are send through the Tunnel.
Luckily the Tunnel does support this by adding a custom configuration to the Tunnel profile that is pushed with Workspace ONE UEM.
If you add the following custom configuration and replace the ‘domain.local’ part with your DFS domain name, you should be good to go. Also see the screenshot below.

<?xml version=”1.0″ encoding=”utf-16″?>
<CustomConfiguration>
<DnsSearchDomain>domain.local</DnsSearchDomain>
</CustomConfiguration>

If you followed the configuration steps to enable the Tunnel to access file shares, as described in the earlier blogpost, the DFS root, namespaces and folders should be now accessible through the Tunnel.
One part might still be a challenge: authentication to these DFS shares still requires Kerberos, so if your device is not domain joined, you will be prompted for authentication:

This might not be the user experience you want to offer to your end users. Most Workspace ONE UEM customers do not want to join their devices to an on-prem Active Directory. The other way to enable Kerberos authentication is to enable Windows Hello For Business, or short H4B. This will take care of the Kerberos authentication and provide a seamless single-sign on experience for your end users.
Microsoft provides a lot of information on H4B here: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification

It might be good to know that Brooks is also working on a guide to show the implementation steps, best practices and lessons learned on H4B. So keep an eye out for that.