All posts tagged configuration

Always On VPN RADIUS Configuration Missing

Windows Server Routing and Remote Access Service (RRAS) is a popular choice for administrators deploying Always On VPN. It is easy to configure and scales out easily. Most commonly, RRAS servers are configured to use RADIUS authentication to provide user authentication for Always On VPN client connections. The RADIUS server can be Microsoft Network Policy and Access Server (NPAS, or simply NPS) or a third-party RADIUS solution. It is best to have the RADIUS service running on a server separate from the RRAS server.

RADIUS Authentication

Administrators can configure RADIUS authentication by opening the Routing and Remote Access management console (rrasmgmt.msc), right-clicking the VPN server, then choosing Properties > Security. Click the Configure button to configure authentication and accounting providers accordingly.

RADIUS Options Missing

In some cases, the administrator will notice that the option to configure RADIUS authentication and accounting servers is missing. In its place is the following error message.

“Because Network Policy Server (NPS) is installed, you must use it to configure authentication and accounting providers. To configure authentication and accounting providers, create or modify connection request policies.”

Configuration Options

It might be tempting for administrators to follow this guidance when presented with this message by opening the Network Policy management console (nps.msc) to configure it. However, that is not recommended or necessary. This message results from a common configuration error that should be corrected.

NPS Role Installed

The error message above occurs when an administrator mistakenly installs the NPAS role on the RRAS server itself. Again, this is not recommended or required. To resolve this issue, uninstall the NPS role by opening an elevated PowerShell command window and running the following command.

Uninstall-WindowsFeature NPAS

Configuration Corrupted

After removing the NPAS role from the RRAS server, administrators may encounter the following error message when configuring RADIUS authentication and accounting servers in RRAS.

“The connection request policy used for authentication and accounting configuration is corrupted. Either install Network Policy Server (NPS) and restore the connection request policy manually, or click Repair Settings to restore the connection request policy by using Windows Accounting and Windows Authentication.”

Repair Settings

To resolve this issue, click the Repair Settings button. Once complete, RADIUS authentication and accounting configuration should work as expected.

Additional Information

Always On VPN Network Policy Server (NPS) Auditing and Logging

Always On VPN Network Policy Server (NPS) Load Balancing

Always On VPN and Windows Server 2019 Network Policy Server (NPS) Bug

Leave a comment
by Richard M. Hicks on October 13, 2022  •  Permalink
Posted in Always On VPN, AOVPN, authentication, Enterprise, enterprise mobility, Mobility, network policy server, NPS, Operational Support, Remote Access, routing and remote access service, RRAS, Security, troubleshooting, user tunnel, VPN, Windows 10, Windows 11, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022
Tagged , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on October 13, 2022

https://directaccess.richardhicks.com/2022/10/13/always-on-vpn-radius-configuration-missing/

Always On VPN DPC with Intune

In the past, I’ve written about PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC), a software solution administrators can use to provision and manage Always On VPN client configuration settings using Active Directory and group policy. In addition to streamlining the deployment and management of Always On VPN client settings, DPC has many advanced features and capabilities to ensure optimal security, performance, and connection reliability.

Optimizations

Many settings required to fine-tune and optimize Always On VPN connections are not exposed in the Intune UI or XML. They must be configured by manipulating configuration files, setting registry keys, and running PowerShell commands. Much of this can be automated using Intune Proactive Remediation, but it is far from ideal. Administrators must configure Always On VPN using one method, then deploy optimizations using another. In addition, Proactive Remediation suffers from timing issues where some settings are not applied immediately, resulting in degraded or inoperable VPN connections until changes take effect.

Always On VPN DPC

Always On VPN DPC allows administrators to configure many advanced settings quickly and conveniently using the familiar Group Policy Management console (gpmc.msc). DPC dramatically reduces the administrative burden associated with Always On VPN client management. In addition, DPC enables many of these options by default, ensuring optimal security and reliable operation. Also, DPC immediately implements all configuration settings, eliminating the need to reboot to apply configuration changes.

Intune and ADMX

Historically, Always On VPN DPC could only be used when managing endpoints exclusively with Active Directory group policy. However, DPC can now be used with Microsoft Endpoint Manager/Intune thanks to a new feature that allows administrators to import custom ADMX and ADML administrative templates to Microsoft Endpoint Manager (MEM).

Note: This feature is in public preview at the time of this writing.

DPC and Intune

The combination of DPC and Intune brings with it many advantages. Using DPC with Microsoft Endpoint Manager/Intune offers administrators simplified deployment and many advanced features provided by Always On VPN DPC. In addition, customers who have deployed DPC on-premises can now migrate seamlessly to Microsoft Endpoint Manager/Intune management without giving up DPC’s valuable features.

Learn More

Enter your contact details in the form below for more information regarding Always On VPN DPC. Also, visit https://aovpndpc.com/ to register for a free Always On VPN DPC trial.

Additional Information

Always On VPN with Active Directory Group Policy

Introduction to Always On VPN DPC

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstrations

What’s New in Always On VPN DPC v3.0

Always On VPN DPC Free Trial

1 Comment
by Richard M. Hicks on October 10, 2022  •  Permalink
Posted in AADJ, Active Directory, administration, Always On VPN, AOVPN, AovpnDPC, Azure, Azure Active Directory, Azure AD, Azure AD Join, Azure VPN, Azure VPN Gateway, cloud, Deployment, Device Management, device tunnel, DPC, Dynamic Profile Configurator, Endpoint Manager, Enterprise, enterprise mobility, Group Policy, HAADJ, Hybrid Azure AD Join, MDM, MEM, MEMCM, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, OMA-DM, Operational Support, PowerShell, ProfileXML, public cloud, Remote Access, SCCM, System Center Configuration Manager, systems management, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on October 10, 2022

https://directaccess.richardhicks.com/2022/10/10/always-on-vpn-dpc-with-intune/

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
  • Enterprise DNS servers (if DNS is running on servers other than 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.

Supportability

Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.

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

79 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/

« Older Posts
%d bloggers like this: