Domain Authentication with Tunnel PerApp VPN

• By -Camille Debay

Domain Authentication with Tunnel PerApp VPN

• Posted on 2021-01-28
• Posted in Business Continuity, Windows Desktop

Story

On Windows when an administrator wants to join a machine to the domain, Microsoft provide 2 solution:

• Online domain join, since Windows 2000, requires to be on the same network of a domain controller, often mentioned as “domain join”.
• Offline domain join, since Windows 7 via command line and Windows 10 1709 via CSP, allow a machine to join the domain without the need to be on the network.

There is no difference between a machine which have join online Vs offline. More info: https://debay.blog/2020/08/12/windows-10-join-method-overview/

Offline Domain Join Process

In the MDM world Offline domain join allow users to join the domain from home, with the Dell Connected provisioning this can even be done in factory.

User first logon issue

Once the machine is domain join, the next step is for the user to logon for the first time. At this point in time, there is no other way but to have a line of sight with the domain controller, there no Windows mechanism to allow this first logon to be offline.

To be able to do it outside of the domain network a VPN is required. This VPN needs to either be a machine VPN or have to be enable on the logon display, it is often referred to Gina VPN because gina was the name of the interface handling the logon and authorization process back in XP.

VMware Tunnel and Domain Authentication

VMware Tunnel is the VMware VPN solution part of Workspace ONE. It is a per app VPN which allow to only tunnel the application which should be on the VPN.

As mentioned before, the VPN needs to run before the user logon, this is possible since 2.0.2 with the following Custom Configuration.

<?xml version='1.0' encoding='utf-16'?>
<CustomConfiguration>
  <StartTunnelPreLogon>true</StartTunnelPreLogon>
</CustomConfiguration>

User Logon Process

Authentication

The process responsible for the User logon is lsass.exe, it is listed in the Windows Services as Netlogon service. It maintains a security channel between the computer and the domain controller to authenticate user and services.

It use the following network communication flow:

Application protocol	Protocol	Ports
NetBIOS Datagram Service	UDP	138 (Optional, used for WINS resolution)
NetBIOS Name Resolution	UDP	137 (Optional, used for WINS resolution)
NetBIOS Session Service	TCP	139 (Optional, used for WINS resolution)
SMB	TCP	445
LDAP	UDP	389
RPC¹	TCP	135, random port number between 49152 – 65535

Reference : https://docs.microsoft.com/en-GB/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#net-logon

The lsass also use Kerberos for the authentication

Application protocol	Protocol	Ports
Kerberos	TCP	88
Kreberos	UDP	88
DC Locator	UDP	389

Reference : https://docs.microsoft.com/en-GB/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#kerberos-key-distribution-center

GPO

Part of the user logon is the application of the user GPO, while this is not ideal to mix CSP and GPO, it is often the case that domain specific GPO are still in the mix. To support GPO synchronization, System need to be added to the Device Traffic rules, this will allow access to the network share where the GPOs are located, i.e: SYSVOL. However GPO also rely on RPC communication as well and the service running the GPO is svchost. As svchost is a generic executable for Windows services it is not advised to add the process in a Device Traffic rule.

Service Name: Group policy client
Command line: %systemroot%\system32\svchost.exe -k netsvcs -p

Application protocol	Protocol	Ports
DCOM	TCP + UDP	random port number between 49152 – 65535
LDAP	TCP	389
SMB	TCP	445
RPC	TCP	135 random port number between 49152 – 65535

Reference: https://docs.microsoft.com/en-GB/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#group-policy

Domain Action Possible

This configuration bring the following support:

• User First logon and subsequent
• GPO
• Password Change for users
• Share folder access
• Printer access
• mmc access to the domain is possible too : require mmc to be on the list of apps

Tunnel Configuration

Device Profile

Add a new VPN profile for Windows Desktop. With the following configuration:

• Server: filled automatically
• Default Traffic Rule Sets: Select the Device Traffic Rules created before
• Desktop Client: Enabled
• Custom Configuration:

<?xml version='1.0' encoding='utf-16'?>
<CustomConfiguration>
  <StartTunnelPreLogon>true</StartTunnelPreLogon>
</CustomConfiguration>

• Trusted Network Detection: enter the FQDN of the AD Domain of the user, this setting allow Tunnel to detect if the machine is already on the corp network.
• Domain: FQDN of the AD Domain and any other domain that needs resolution via VPN

Assign it to the Staging User and the End User via Smart Groups and make sure that the assignment is at Auto

Now everything is ready for the End User to open the session without the need to be on the network.