All posts tagged Microsoft

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Operation and Best PracticesUnlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.

Device Tunnel Use Cases

The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).

Device Tunnel Requirements

The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.

Device Tunnel Authentication

The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.

Always On VPN Device Tunnel Operation and Best Practices

CRL Checking

Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.

Configuration Best Practices

As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.

Required

  • All domain controllers

Optional

  • All issuing certification authority (CA) servers
  • All certificate services online HTTP responders
  • All certificate services Online Certificate Status Protocol (OCSP) servers
  • System Center Configuration Manager (SCCM) distribution point servers
  • Windows Server Update Services (WSUS) servers
  • Management workstations

Limiting Access

Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.

Traffic Filters

The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.

Host Routes

An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.

Always On VPN Device Tunnel Operation and Best Practices

Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.

Caveats

Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.

Tunnel Coexistence

The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.

DNS Registration

If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

10 Comments
by Richard M. Hicks on March 30, 2020  •  Permalink
Posted in Always On VPN, AOVPN, certificates, device tunnel, Enterprise, enterprise mobility, IKEv2, Manage Out, Microsoft Intune, Mobility, network policy server, NPS, Operational Support, PowerShell, ProfileXML, public key infrastructure, Remote Access, routing and remote access service, RRAS, Security, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 30, 2020

https://directaccess.richardhicks.com/2020/03/30/always-on-vpn-device-tunnel-operation-and-best-practices/

Always On VPN Trusted Network Detection

Always On VPN Trusted Network DetectionWhen deploying Windows 10 Always On VPN, administrators can configure Trusted Network Detection (TND) which enables clients to detect when they are on the internal network. With this option set, the client will only automatically establish a VPN connection when it is outside the trusted network. Trusted network detection can be configured on both device tunnel and user tunnel connections.

TND Operation

When trusted network detection is configured, the VPN client will evaluate the DNS suffix assigned to all physical (non-virtual or tunnel) adapters that are active. If any of them match the administrator-defined trusted network setting, the client is determined to be on the internal network and the VPN connection will not connect. If the DNS suffix is not present on any of these adapters, the client is determined to be outside the internal network and the VPN connection will establish automatically.

TND Configuration

Trusted network detection is defined in the Intune UI or in ProfileXML as a string that matches the DNS suffix assigned to clients on the internal network. In this example, the DNS suffix on the internal network is lab.richardhicks.net.

Always On VPN Trusted Network Detection

Note: Your organization might have more than one DNS suffix. Ensure that the trusted network detection configuration includes all DNS suffixes in use in the environment to ensure reliable operation.

Intune

Follow the steps below to configured trusted network detection in Microsoft Intune.

  1. Open the Intune management portal (https://devicemanagement.microsoft.com/).
  2. Navigate to Devices > Configuration Profiles > [Profile Name] > Properties > Settings.
  3. Click on Trusted Network Detection.
  4. Enter the DNS suffix(es) used on the internal network.

Always On VPN Trusted Network Detection

ProfileXML

To define Trusted Network Detection in ProfileXML, add the TrustedNetworkDetection element as follows.

Always On VPN Trusted Network Detection

Caveats

In some instances, an Always On VPN client connection may persist, even if the client is connected to the internal network. A common scenario is when a client device connects to a Wi-Fi network that is not connected to the corporate network (for example guest Wi-Fi), then connects to the internal network with Ethernet via a docking station. If the Wi-Fi connection is still available, the Always On VPN connection will persist, even though the machine is connected to the internal network. This is expected and by design.

Workaround

To address this specific scenario, administrators can implement changes via group policy to the way Windows handles multiple connections to the same network. For example, beginning with Windows 10 1709, group policy can be configured to ensure that Windows 10 clients prefer wired Ethernet network connections over Wi-Fi, and to ensure that Wi-Fi connections disconnect when an Ethernet connection is detected.

GPO Configuration

Open the Group Policy management console (gpmc.msc) and perform the following steps to create the required group policy objects.

  1. Create a new Group Policy Object (GPO).
  2. Right-click the new GPO and choose Edit.
  3. Expand Computer Configuration > Administrative Templates > Network > Windows Connection Manager.
  4. Double-click the policy Minimize the number of simultaneous connections to the Internet or a Windows Domain.
  5. Select Enabled.
  6. From the Minimize Policy Options drop-down list choose 1 = Minimize simultaneous connections. Optionally you can choose to disable Wi-Fi whenever connected to Ethernet by choosing 3 = Prevent Wi-Fi when on Ethernet.
  7. Click Ok.Always On VPN Trusted Network Detection
  8. Double-click the policy Enable Windows to soft-disconnect a computer from a network.
  9. Select Disabled.
  10. Click Ok.Always On VPN Trusted Network Detection

Additional Information

Understanding and Configuring Windows Connection Manager

5 Comments
by Richard M. Hicks on March 24, 2020  •  Permalink
Posted in administration, Always On VPN, AOVPN, device tunnel, Enterprise, enterprise mobility, Microsoft Intune, Mobility, Operational Support, ProfileXML, Remote Access, routing and remote access service, RRAS, troubleshooting, user tunnel, Windows 10
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 24, 2020

https://directaccess.richardhicks.com/2020/03/24/always-on-vpn-trusted-network-detection/

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Troubleshooting Always On VPN Error 691 and 812 – Part 2A while back I wrote about troubleshooting and resolving Windows 10 Always On VPN errors 691 and 812. There are numerous issues that can result in these errors, and in that post I pointed out they can be caused by disabling TLS 1.0 on Windows Servers prior to Windows Server 2016. However, administrators may encounter a another scenario in which they receive errors 691 or 812 which is related to Active Directory user account configuration.

SSTP and Error 691

When attempting to establish an Always On VPN connection using the Secure Socket Tunneling Protocol (SSTP), administrators may encounter the following error message.

“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

In addition, an error 691 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

“The user <domain\user> dialed a connection named which has failed. The error code returned on failure is 691.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

IKEv2 and Error 812

When attempting to establish an Always On VPN connection using Internet Key Exchange version 2 (IKEv2), administrators may encounter the following error message.

“The connection as prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

In addition, an error 812 with event ID 20227 from the RasClient source can be found in the Application event log on the client.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

NPS Event Log

On the NPS server the administrator will find an entry in the application event log with event ID 6273 from the Microsoft Windows security auditing source and the Network Policy Server task category indicating the network policy server denied access to the user. Looking closely at this event log message shows Reason Code 65 and the following reason.

“The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.”

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Resolution

There are two options available to address this issue. The user account in Active Directory can be configured to grant access or allow access to be controlled via NPS network policy, or the NPS network policy can be configured to ignore user account dial-in properties.

User Account

Follow the steps below to change Network Access Permission on an individual user’s Active Directory account.

  1. Open the Active Directory User and Computers (ADUC) management console (dsa.msc) and double-click the user’s account.
  2. Select the Dial-in tab.
  3. In the Network Access Permission section select the option to Allow access or Control access through NPS Network Policy.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Note: If you do not see the dial-in tab, open the ADUC console on a domain controller. The dial-in tab is not displayed when using the Remote Server Administration Tools (RSAT) for Windows clients.

Network Policy

Follow the steps below to configure NPS network policy to ignore user account dial-in properties.

  1. Open the NPS management console (nps.msc) and double-click the Always On VPN network policy.
  2. In the Access Permission section select Ignore user account dial-in properties.
  3. Click Ok to save the changes.

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Additional Information

Windows 10 Always On VPN Troubleshooting Error 691 and 812

Leave a comment
by Richard M. Hicks on February 17, 2020  •  Permalink
Posted in Always On VPN, AOVPN, Enterprise, enterprise mobility, IKEv2, Mobility, network policy server, NPS, Remote Access, routing and remote access service, RRAS, Security, troubleshooting, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 17, 2020

https://directaccess.richardhicks.com/2020/02/17/troubleshooting-always-on-vpn-error-691-and-812-part-2/

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice when the highest level of security is required for Always On VPN connections. It uses IPsec and features configurable security parameters that allow administrators to adjust policies to meet their specific security requirements. IKEv2 is not without some important limitations, but organizations may insist on the use of IKEv2 to provide the greatest protection possible for remote connected clients. Due to complexities of the IKEv2 transport, special configuration on the Citrix ADC is required when load balancing this workload.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing IKEv2

When an Always On VPN client establishes a connection using IKEv2, communication begins on UDP port 500, but switches to UDP port 4500 if Network Address Translation (NAT) is detected in the communication path between the client and the server. Because UDP is connectionless, custom configuration is required to ensure that VPN clients maintain connectivity to the same backend VPN server during this transition.

Initial Configuration

Load balancing IKEv2 using the Citrix ADC is similar to other workloads. Below are specific settings and parameters required to load balance IKEv2 using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing services for IKEv2 VPN will use UDP ports 500 and 4500. Create the service group and assign group members for UDP 500 as follows.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the service group for UDP port 4500.

Virtual Server Settings

Two virtual servers are required, one for UDP port 500 and one for UDP port 4500. Ensure that the service group using UDP port 500 is bound to the virtual server using the same port.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the virtual service for UDP port 4500.

Service Monitoring

Since IKEv2 uses the UDP protocol, the only option for service monitoring is to use PING, which is configured by default. Ensure that the firewall on the VPN server allows inbound ICMPv4 and ICMPv6 Echo Request. The default PING monitor on the Citrix ADC will ping the resource every 5 seconds. If a different interval is required, the administrator can edit the PING monitor and bind that to the service or service group as necessary.

Persistency Group

A Persistency Group on the Citrix ADC will be configured to ensure that IKEv2 VPN client requests from the same client are always routed to the same backend server. Follow the steps below to create a Persistency Group and assign it to both IKEv2 virtual servers created previously.

1. In the Citrix ADC management console expand Traffic Management > Load Balancing > Persistency Groups.
2. Click Add.
3. Enter a descriptive name for the Persistency Group.
4. Select SOURCEIP from the Persistence drop-down list.
5. Next to the Virtual Server Name section click the Add button.
6. Add both previously configured IKEv2 virtual servers for UDP 500 and 4500.
7. Click Create.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Additional Information

Windows 10 Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 AlWAYS On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

5 Comments
by Richard M. Hicks on January 20, 2020  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, Citrix ADC, device tunnel, Enterprise, enterprise mobility, High Availability, IKEv2, Load Balancing, Mobility, Netscaler, Remote Access, routing and remote access service, RRAS, Security, user tunnel, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 20, 2020

https://directaccess.richardhicks.com/2020/01/20/always-on-vpn-ikev2-load-balancing-with-citrix-netscaler-adc/

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN Device Tunnel with Azure VPN GatewayAlways On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

Always On VPN Device Tunnel with Azure VPN Gateway

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Always On VPN Device Tunnel with Azure VPN Gateway

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

Always On VPN Device Tunnel with Azure VPN Gateway

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Always On VPN Device Tunnel with Azure VPN Gateway

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Always On VPN Device Tunnel with Azure VPN Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

6 Comments
by Richard M. Hicks on January 6, 2020  •  Permalink
Posted in Always On VPN, AOVPN, Azure, Azure VPN, Azure VPN Gateway, certificates, device tunnel, Encryption, Enterprise, enterprise mobility, IKEv2, Microsoft Intune, Mobility, PowerShell, ProfileXML, public cloud, Remote Access, Security, Windows 10, XML
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 6, 2020

https://directaccess.richardhicks.com/2020/01/06/always-on-vpn-device-tunnel-with-azure-vpn-gateway/

Microsoft Intune NDES Connector Error 0x80004003

Microsoft Intune NDES Connector Error 0x80004003To support certificate deployment for non-domain Windows 10 Always On VPN clients, a Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Connection Status Error

After installing the Microsoft Intune Connector, the administrator may encounter the following error message.

“An error occurred while connecting to the Intune Service. Error code is 0x80004003. The NDES Connector will retry the connection as soon as possible.”

 Microsoft Intune NDES Connector Error 0x80004003

IE Enhanced Security Configuration

This error can occur if Internet Explorer Enhanced Security Configuration (ESC) is enabled. To resolve this issue, disable ESC for administrators and users by opening the Server Manager on the NDES server and performing the following steps.

1. In the navigation pane click Local Server.
2. Click the On link next to IE Enhanced Security Configuration.
3. Click Off in the Administrators section.
4. Click Off in the Users section
5. Click Ok.

Microsoft Intune NDES Connector Error 0x80004003

Once complete, restart the NDES Connector service using the following PowerShell command.

Restart-Service NDESConnectorSvc -PassThru

Additional Configuration

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Leave a comment
by Richard M. Hicks on November 25, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, Azure, Enterprise, enterprise mobility, Microsoft Intune, Mobility, NDES, Network Device Enrollment Service, Network Device Enrollment Services, PKI, public cloud, public key infrastructure, Remote Access, Security, troubleshooting, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2019
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 25, 2019

https://directaccess.richardhicks.com/2019/11/25/microsoft-intune-ndes-connector-error-0x80004003/

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

12 Comments
by Richard M. Hicks on November 18, 2019  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, device tunnel, enterprise mobility, High Availability, Hotfix, IKEv2, Kemp, Load Balancing, LoadMaster, Mobility, Remote Access, routing and remote access service, RRAS, troubleshooting, Update, user tunnel, VPN, Windows 10, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 18, 2019

https://directaccess.richardhicks.com/2019/11/18/always-on-vpn-ikev2-load-balancing-issue-with-kemp-loadmaster/

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Microsoft Intune NDES Connector Setup Wizard Ended PrematurelyA Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

 

6 Comments
by Richard M. Hicks on November 11, 2019  •  Permalink
Posted in Always On VPN, AOVPN, authentication, Azure, certificates, cloud, Encryption, Enterprise, enterprise mobility, InTune, Microsoft Intune, Mobility, NDES, Network Device Enrollment Service, Network Device Enrollment Services, PKI, public cloud, public key infrastructure, Remote Access, Security, systems management, troubleshooting, user tunnel, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 11, 2019

https://directaccess.richardhicks.com/2019/11/11/microsoft-intune-ndes-connector-setup-wizard-ended-prematurely/

Always On VPN Load Balancing with Kemp in Azure

Always On VPN Load Balancing with Kemp in AzureIn a recent post I discussed options for load balancing Windows Server Routing and Remote Access Service (RRAS) in Microsoft Azure for Always On VPN. There are many choices available to the administrator, however the best alternative is to use a dedicated Application Delivery Controller (ADC), or load balancer. The Kemp LoadMaster load balancer is an excellent choice here, as it is easy to configure and deploy. It is also very cost effective and offers flexible licensing plans, including a metered licensing option.

Deploy LoadMaster in Azure

To provision a Kemp LoadMaster load balancer in Microsoft Azure, open the Azure management console and perform the following steps.

1. Click Create Resource.
2. Enter LoadMaster in the search field.
3. Click on LoadMaster Load Balancer ADC Content Switch.

Always On VPN Load Balancing with Kemp in Azure

4. Choose an appropriate license model from the Select a software plan drop-down list.
5. Click Create.

Prepare Azure Instance

Follow the steps below to provision the Azure VM hosting the Kemp LoadMaster load balancer.

1. Choose an Azure subscription to and resource group to deploy the resources to.
2. Provide instance details such as virtual machine name, region, availability options, and image size.
3. Select an authentication type and upload the SSH private key or provide a username and password.
4. Click Next:Disks >.

Always On VPN Load Balancing with Kemp in Azure

5. Select an OS disk type.
6. Click Next: Networking >.

Always On VPN Load Balancing with Kemp in Azure

7. Select a virtual network and subnet for the load balancer.
8. Create or assign a public IP address.
9. Click Review + create.

Always On VPN Load Balancing with Kemp in Azure

LoadMaster Configuration

Once the virtual machine has been provisioned, open a web browser and navigate to the VM’s internal IP address on port 8443 to accept the licensing terms.

Always On VPN Load Balancing with Kemp in Azure

Next, log in with your Kemp ID and password to finish licensing the appliance.

Always On VPN Load Balancing with Kemp in Azure

Finally, log in to the appliance using the username ‘bal’ and the password provided when the virtual machine was configured.

Always On VPN Load Balancing with Kemp in Azure

Azure Network Security Group

A Network Security Group (NSG) is automatically configured and associated with the LoadMaster’s network interface when the appliance is created. Additional inbound security rules must be added to allow VPN client connectivity.

In the Azure management console open the properties for the LoadMaster NSG and follow the steps below to configure security rules to allow inbound VPN protocols.

SSTP

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 443 in the Destination port ranges field.
7. Select the TCP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.

Always On VPN Load Balancing with Kemp in Azure

IKEv2

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 500 in the Destination port ranges field.
7. Select the UDP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.
12. Repeat the steps below for UDP port 4500.

Always On VPN Load Balancing with Kemp in Azure

Load Balancing SSTP and IKEv2

Refer to the following posts for detailed, prescriptive guidance for configuring the Kemp LoadMaster load balancer for Always On VPN load balancing.

Always On VPN SSTP Load Balancing with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing with the Kemp LoadMaster

Always On VPN Load Balancing Deployment Guide for the Kemp LoadMaster

Summary

Although Windows Server RRAS is not a formally supported workload in Azure, it is still a popular and effective solution for Always On VPN deployments. The Kemp LoadMaster load balancer can be deployed quickly and easily to provide redundancy and increase scalability for larger deployments.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancers

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancers

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp LoadMaster Load Balancers

Deploying the Kemp LoadMaster Load Balancer in Microsoft Azure

1 Comment
by Richard M. Hicks on November 4, 2019  •  Permalink
Posted in ADC, Always On VPN, AOVPN, application delivery controller, Azure, Azure VPN, Enterprise, enterprise mobility, High Availability, IKEv2, Kemp, Load Balancing, LoadMaster, Mobility, public cloud, Remote Access, routing and remote access service, RRAS, SSTP, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 4, 2019

https://directaccess.richardhicks.com/2019/11/04/always-on-vpn-load-balancing-with-kemp-in-azure/

Troubleshooting Always On VPN Error Code 864

When configuring an Always On VPN connection, the administrator may encounter a scenario in which a VPN connection fails using either Internet Key Exchange version 2 (IKEv2) or Secure Socket Tunneling Protocol (SSTP). On the Windows 10 client the error message states the following.

“Can’t connect to [connection name]. The remote access connection completed, but authentication failed because a certificate that validates the server certificate was not found in the Trusted Root Certification Authorities certificate store.”

Troubleshooting Always On VPN Error Code 864

In addition, the Application event log records an error message with Event ID 20227 from the RasClient source. The error message states the following.

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

Troubleshooting Always On VPN Error Code 864

NPS Server Certificate

Error code 864 is commonly caused by a missing or invalid server certificate on the Network Policy Server (NPS) performing authentication for VPN clients. The NPS server must have a certificate installed in its local computer certificate store from a trusted certification authority (CA) that includes the following.

Subject Name

The subject name must match the hostname defined in the EAP configuration for VPN clients. This may be the NPS server’s hostname but could also be an alias when NPS load balancing is configured.

Troubleshooting Always On VPN Error Code 864

Enhanced Key Usage

The NPS server certificate must include the Server Authentication Enhanced Key Usage (EKU).

Troubleshooting Always On VPN Error Code 864

NPS Policy Configuration

The NPS server certificate must also be selected in the network policy used for VPN client authentication. To confirm correct certificate configuration, open the properties for the Always On VPN network policy and follow the steps below.

1. Select the Constraints tab.
2. Highlight Authentication Methods.
3. Highlight Microsoft: Protected EAP (PEAP) in the EAP Types field.
4. Click Edit.
5. Select the NPS server certificate from the Certificate issued to drop-down list.

Troubleshooting Always On VPN Error Code 864

Ensure the NPS server certificate is also used for client certificate authentication by performing the following steps.

1. Highlight Smart Card or other certificate.
2. Click Edit.
3. Select the NPS server certificate from the Certificate issued to drop-down list.
4. Click Ok.

Troubleshooting Always On VPN Error Code 864

Additional Information

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

1 Comment
by Richard M. Hicks on October 31, 2019  •  Permalink
Posted in Always On VPN, AOVPN, certificates, enterprise mobility, IKEv2, Mobility, network policy server, public key infrastructure, Remote Access, Security, troubleshooting, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on October 31, 2019

https://directaccess.richardhicks.com/2019/10/31/troubleshooting-always-on-vpn-error-code-864/

« Older Posts
%d bloggers like this: