Always On VPN and Azure MFA ESTS Token Error

Always On VPN and Azure MFA ESTS Token ErrorConfiguring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. Azure MFA is widely deployed and commonly integrated with Windows Server Network Policy Server (NPS) using the NPS Extension for Azure MFA. Azure MFA has a unique advantage over many other MFA providers in that it supports MFA when using Protected Extensible Authentication Protocol (PEAP). This makes Azure MFA the solution of choice for integrating with Windows 10 Always On VPN deployments using client certificate authentication, a recommended security configuration best practice.

NPS Configuration

Installing and configuring the NPS extension for Azure MFA is straightforward. Configuration guidance from Microsoft can be found here.

Connection Issues

After installing the NPS extension for Azure MFA, administrators may find that Always On VPN connections fail and the user is never challenged for authentication. The connection eventually times out and returns the following error message.

“A connection to the remote computer could not be established, so the port used for this connection was closed.”

Always On VPN and Azure MFA ESTS Token Error

In addition, the Application event log on the Windows 10 client contains an Event ID 20221 from the RasClient source that includes the following error message.

“The user [username] dialed a connection named [connection] which has failed. The error code returned on failure is 0.”

Always On VPN and Azure MFA ESTS Token Error

NPS Event Log

Reviewing the event logs on the NPS server reveals more information. The Security event log contains an Event ID 6274 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server discarded the request for a user. Contact the Network Policy Administrator for more information.”

Always On VPN and Azure MFA ESTS Token Error

ESTS Token Error

Digging deeper in the operational event log on the NPS server, the AuthZAdminCh log (Applications and Services Logs > Microsoft > AzureMfa > AuthZ) contains an Event ID 3 from the AuthZ source indicating an ESTS_TOKEN_ERROR message.

Always On VPN and Azure MFA ESTS Token Error

Troubleshooting ESTS Token Error

Follow the steps below to troubleshoot the ESTS_TOKEN_ERROR.

Prerequisites

Ensure that all prerequisites are met. Validate the user is being synced to Azure Active Directory and that it is properly licensed for Azure MFA.

Certificates

As part of the NPS extension configuration, a certificate is created on the NPS server that is uploaded to Azure Active Directory. To validate the certificate was created and uploaded correctly, follow the troubleshooting guidance found here.

Enterprise Applications

The Azure Multi-Factor Auth Client and the Azure Multi-Factor Auth Connector enterprise applications must be enabled to support the NPS extension for Azure MFA. To confirm they are enabled, open an elevated PowerShell command window on the server where the Azure AD Connector is installed and run the following PowerShell commands.

Import-Module MSOnline
Connect-MsolService

Get-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” | Select-Object DisplayName, AccountEnabled

Get-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” | Select-Object DisplayName, AccountEnabled

Always On VPN and Azure MFA ESTS Token Error

If either or both enterprise applications are not enabled, enable them using the following PowerShell commands.

Set-MsolServicePrincipal -AppPrincipalId “981f26a1-7f43-403b-a875-f8b09b8cd720” -AccountEnabled $True

Set-MsolServicePrincipal -AppPrincipalId “1f5530b3-261a-47a9-b357-ded261e17918” -AccountEnabled $True

Once complete, restart the IAS service on the NPS server using the following PowerShell command.

Restart-Service IAS -PassThru

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing Strategies

Deploy Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes Now Available

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or ComputersOnce Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.

Certificate Revocation

When certificates are used for authentication, for example when a device tunnel is deployed, or a user tunnel is configured to use Extensible Authentication Protocol (EAP) with user certificate authentication, immediately revoking issued user and device certificates and publishing a new Certificate Revocation List (CRL) is recommended. However, this will not instantly prevent VPN access because revocation information is cached on the VPN and NPS servers, as well as any online responders. The process of flushing certificate revocation caches is challenging and time consuming as well.

Blocking Users

To immediately prevent users from accessing the VPN, a security group must be created in Active Directory that contains users that will be denied access. In addition, a Network Policy must be created on the Network Policy Server (NPS) that denies access to users belong to this security group.

NPS Configuration

Once the security group has been created, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand Policies.
  2. Right-click Network Policies and choose New.
  3. Enter a descriptive name for the policy in the Policy name field.
  4. Select Remote Access Server (VPN-Dial up) from the Type of network access server drop-down list.
  5. Click Next.
  6. Click Add.
    1. Select User Groups.
    2. Click Add.
    3. Click Add Groups.
    4. Select the security group create for denied users.
    5. Click Ok twice.
  7. Click Next.
  8. Select Access denied.
  9. Click Next four times and click Finish.

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or Computers

Once complete, move the deny access policy so that it is before the policy that allows VPN access.

Denying Access to Always On VPN Users or Computers

Device Tunnel Considerations

Since device tunnel connections don’t use the NPS for authentication, blocking devices from establishing Always On VPN connections requires a different technique. Once again, revoking the computer certificate and publishing a new CRL is recommended, but isn’t immediately effective. To address this challenge, it is recommended that the computer certificate issued to the client be retrieved from the issuing CA and placed in the local computer’s Untrusted Certificates store on each VPN server, as shown here.

Note: The certificate must be imported on each VPN server in the organization.

Terminating Connections

Once the guidance above is put in to place, any user or device that is denied access will be unable to connect to the VPN. However, if a user or device is currently connected when these changes are implemented, additional steps must be taken to proactively terminate their existing session. When using Windows Server Routing and Remote Access Service (RRAS) as the VPN server, uUser sessions can be proactively terminated using RRAS management console or PowerShell.

GUI

To terminate an established Always On VPN connection, open the RRAS management console (rrasmgmt.msc), highlight Remote Access Clients, then right-click the client connection and choose Disconnect. Repeat the process for any additional connections established by the user or device.

Denying Access to Always On VPN Users or Computers

PowerShell

Alternatively, Always On VPN connections can also be terminated programmatically using PowerShell. To identify currently connected users on a VPN server, open an elevated PowerShell command window and run the following command.

Get-RemoteAccessConnectionStatistics | Format-Table -AutoSize

Next, to disconnect a user tunnel, identify the User Principal Name (UPN) of the user to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “[email protected]

To disconnect a device tunnel, identify the Fully-Qualified Domain Name (FQDN) of the device to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “client1.corp.example.net”

Additional Information

Windows 10 Always On VPN Hands-On Training

Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained