All posts in category systems management

Always On VPN and Interface Metrics

Always On VPN DNS Registration Update Available

In Windows, each network interface identified by the operating system is assigned a metric value. Interface metrics are settings that determine the priority or preference of network interfaces when there are multiple active network connections. The Windows networking stack uses these metrics to determine which network interface should be used for routing traffic when multiple network interfaces are available. Network interface metrics are critical for Always On VPN administrators to understand because they can impact how name resolution requests are processed when an Always On VPN connection is established.

Metric Values

By default, Windows automatically assigns metric values to network interfaces (including VPN interfaces) based on various factors, including the connection speed, link state, and interface type. It tries to select the most suitable interface for general internet connectivity.

Metrics and DNS

Windows will also use the network interface with the lowest metric value as the preferred interface for sending DNS queries by default. This means that DNS queries will be routed through the network interface with the lowest metric value, assuming it is available and connected. When an Always On VPN connection is established, DNS queries may fail or return unexpected results if the network interface metrics are not configured optimally.

Split DNS and Wired Ethernet

Split DNS (sometimes called ‘split brain DNS’) is when the DNS namespace is the same internally and externally. The most common scenario where interface metric settings interfere with DNS operation is when using split DNS and the endpoint is connected to the Internet with a wired Ethernet connection. In this scenario, the Ethernet interface will be assigned the same or lower interface metric value as the Always On VPN interface, which can yield unexpected results.

Viewing Metrics

Always On VPN administrators can view currently assigned interface metric values by running the following PowerShell command.

Get-NetIpInterface

Assigning Metrics

Most Always On VPN administrators will never have to change interface metric settings. However, if your implementation uses split DNS and some of your endpoints connect using wired Ethernet connections, you may need to update the interface metric settings to ensure proper DNS operation. Choose a setting for the interface metric value that is lower than the wired Ethernet interface. I’ve used a value of ‘3’ without issue for many years. Use one of the following methods to update the interface metric for Always On VPN connections.

PowerShell

Updating interface metric settings in Windows can be accomplished by running the Set-NetIpInterface PowerShell command.

Set-NetIpInterface -InterfaceAlias <connection name> -InterfaceMetric 3

Note: Using PowerShell to assign the interface metric is not persistent! While this method is suitable for local validation testing, you should use one of the following methods to implement this change permanently.

Rasphone.pbk

To assign the interface metric permanently, Always On VPN administrators can edit the following settings in the rasphone.pbk configuration file.

IpInterfaceMetric=3

Ipv6InterfaceMetric=3

Administrators can automate updating this setting using the Update-Rasphone.ps1 PowerShell script. In addition, the following scripts can be used with Microsoft Intune remediation.

Detect-DeviceIpv4InterfaceMetric.ps1

Remediate-DeviceIpv4InterfaceMetric.ps1

Detect-DeviceIpv6InterfaceMetric.ps1

Remediate-DeviceIpv6InterfaceMetric.ps1

Detect-Ipv4InterfaceMetric.ps1

Remediate-Ipv4InterfaceMetric.ps1

Detect-Ipv6InterfaceMetric.ps1

Remediate-Ipv6InterfaceMetric.ps1

DPC

Organizations using PowerON Platforms’ Dynamic Profile Configurator (DPC) to manage Always On VPN client configuration settings with Active Directory and group policy or Microsoft Intune can enable the VPN Tunnel Metric setting.

Additional Information

Get-NetIpInterface PowerShell Command

Set-NetIpInterface PowerShell Command

Managing Always On VPN Client Settings with DPC

Always On VPN DPC with Microsoft Intune

Always On VPN DPC Advanced Features

Always On VPN DPC Video Demonstration

PowerON Platforms Always On VPN Dynamic Profile Configurator (DPC)

7 Comments
by Richard M. Hicks on September 25, 2023  •  Permalink
Posted in Active Directory, administration, Always On VPN, Always On VPN DPC, AOVPN, AovpnDPC, Deployment, Device Management, device tunnel, DNS, DPC, Dynamic Profile Configurator, Endpoint Manager, Enterprise, enterprise mobility, Group Policy, HAADJ, Hybrid Azure AD Join, Infrastructure, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Name Resolution, Operational Support, PowerShell, ProfileXML, Remote Access, Split DNS, split tunnel, split tunneling, systems management, user tunnel, VPN, Windows 10, Windows 11, XML
Tagged , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on September 25, 2023

https://directaccess.richardhicks.com/2023/09/25/always-on-vpn-and-interface-metrics/

Azure Conditional Access Certificates with SID Information Now Available

I recently wrote about changes to certificate-based authentication affecting Always On VPN implementations. These changes were introduced by Microsoft’s security update KB5014754. When the update is installed on domain controllers and enterprise Certification Authorities (CAs), administrators can perform strong user mapping for certificates used for Active Directory authentication. However, when first introduced, the update came with some serious limitations that prevented administrators from enabling full enforcement mode for certificate mapping.

Limitations

When KB5014754 is installed on an enterprise issuing CA, a new certificate extension (1.3.6.1.4.1.311.25.2) is added to the issued certificate that includes the principal’s (user or device) Security Identifier (SID). However, this only occurs when an online template is used. An online template is one with the subject name built from Active Directory information. The SID is not embedded in certificates issued using an offline template. Offline templates are templates where the subject name is supplied in the request. There are two scenarios where this causes problems for Always On VPN.

Microsoft Intune

Certificates delivered with Microsoft Intune via the Intune Certificate Connector use an offline template. This applies to certificates using PKCS or SCEP. Today, the SID is not embedded by issuing CAs using offline templates.

Azure Conditional Access

The short-lived certificate issued by Azure when Conditional Access is configured for Always On VPN did not include the SID. However, that recently changed.

Recent Updates

Today we can scratch Azure Conditional Access off the list of limitations for Always On VPN. Microsoft recently introduced support for the new SID extension in Azure Conditional Access certificates, as shown here.

Now when an Azure Conditional Access certificate is issued to an on-premises user or device account that is synced with Azure Active Directory, Azure Conditional Access will include the SID information in the issued short-lived certificate.

Intune

Unfortunately, we’re still waiting for Microsoft to address the limitation with certificates delivered using Microsoft Intune. Hopefully we’ll see an update for that later this year.  

Additional Information

Certificate-Based Authentication Changes and Always On VPN

Microsoft KB5014754

Digital Certificates and TPM

Microsoft Intune Certificate Connector Service Account and PKCS

2 Comments
by Richard M. Hicks on July 11, 2023  •  Permalink
Posted in AADJ, Active Directory, administration, Always On VPN, AOVPN, authentication, Azure, Azure Active Directory, Azure AD, Azure AD Join, Azure Conditional Access, Azure MFA, Azure VPN, Certificate Connector for Intune, certificates, cloud, Conditional Access, Deployment, Device Management, Endpoint Manager, Enterprise, enterprise mobility, HAADJ, Hybrid Azure AD Join, Infrastructure, InTune, Intune Certificate Connector, Intune PFX Connector, MDM, MEM, MEMCM, MFA, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, Multifactor Authentiction, NDES, Network Device Enrollment Service, Network Device Enrollment Services, NPS, Operational Support, PFX Connector, PKCS, PKI, public cloud, public key infrastructure, Remote Access, SCEP, Security, Simple Certificate Enrollment Protocol, systems management, Update, user tunnel, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 11, 2023

https://directaccess.richardhicks.com/2023/07/11/azure-conditional-access-certificates-with-sid-information-now-available/

Always On VPN Trusted Network Detection and Native Azure AD Join

Administrators deploying Microsoft Always On VPN are quickly learning that the native Azure Active Directory join (AADJ) model has significant advantages over the more traditional Hybrid Azure AD join (HAADJ) scenario. Native AADJ is much simpler to deploy and manage than HAADJ while still allowing full single sign-on (SSO) to on-premises resources for remote users. Intune even allows for the import of custom ADMX and ADML administrative templates, further reducing the dependency on on-premises Active Directory for device management.

Remote Management

Although devices aren’t joined to the domain, administrators may still wish to access those clients connected to their network for device discovery or to perform administrative tasks. However, when native AADJ clients connect via Always On VPN, the Public Windows firewall profile is assigned to the VPN tunnel adapter. The Public profile is, of course, more restrictive and blocks most management protocols by default.

Firewall Rules

While adding firewall rules to the Public profile to allow management protocols is possible, this isn’t recommended for security reasons. The Public profile is typically loaded when the device is on an untrusted network. Exposing management protocols on an insecure network is asking for trouble.

Domain Profile

Domain-joined or Hybrid AADJ endpoints will use the Domain Windows firewall profile. This profile is more permissive, allowing many standard management protocols by default. Also, administrators can add rules to allow additional access as required without increasing the risk for devices on untrusted networks.

Trusted Network Detection

So, the trick is to get a native AADJ endpoint to load the Domain profile for the VPN tunnel adapter when connected via Always On VPN. Trusted Network Detection is accomplished by using settings configured on the endpoint using the NetworkListManager Configuration Service Provider (CSP).

Intune and XML

There are two settings administrators can enable AADJ devices to detect a trusted network and load the Domain Windows firewall profile. Unfortunately, these settings can only be applied using Intune and the Custom XML template. Administrators will use the following OMA-URI settings.

AllowedTlsAuthenticationEndpoints

The AllowedTlsAuthenticationEndpoints policy setting defines the URL the device uses to validate a trusted network. The target must be an on-premises web server with a valid TLS certificate using HTTPS. The target must be a highly available internal resource inaccessible from the Internet. DirectAccess administrators will be quite familiar with this concept; it’s the Network Location Server (NLS)!

Use the following OMA-URI to configure the TLS authentication endpoint.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/AllowedTlsAuthenticationEndpoints

String: <![CDATA[https://nls.corp.example.net]]>

ConfiguredTlsAuthenticationNetworkName

The ConfiguredTlsAuthenticationNetworkName policy setting is optional. Administrators can use this setting to provide a friendly name for the authenticated trusted network. The FQDN of the target resource (NLS) is used by default. However, using this setting overrides the default with something more meaningful.

Use the following OMA-URI to configure the TLS authentication network name.

URI: ./Device/Vendor/MSFT/Policy/Config/
NetworkListManager/ConfiguredTlsAuthenticationNetworkName

String: <Friendly network name>

Results

Once configured, you’ll find the Always On VPN tunnel adapter uses the Domain Windows firewall profile and an optional friendly network name.

Additional Information

Deploying Always On VPN with Intune using Custom XML and CSP

Always On VPN CSP Updates

Always On VPN and VpnStrategy with CSP

2 Comments
by Richard M. Hicks on June 26, 2023  •  Permalink
Posted in AADJ, Active Directory, administration, Always On VPN, AOVPN, authentication, Azure Active Directory, Azure AD, Azure AD Join, certificates, Deployment, Device Management, Endpoint Manager, Enterprise, enterprise mobility, Group Policy, HAADJ, Hybrid Azure AD Join, Manage Out, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Intune, Mobile Device Management, Mobility, OMA-DM, OMA-URI, Operational Support, Remote Access, Security, SSL, SSL and TLS, systems management, TLS, TND, Trusted Network Detection, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 26, 2023

https://directaccess.richardhicks.com/2023/06/26/always-on-vpn-trusted-network-detection-and-native-azure-ad-join/

« Older Posts
Newer Posts »
%d