All posts in category Mobility

Microsoft Entra Private Network Connector Overview and Deployment Strategies

When deploying Microsoft Entra Private Access, administrators must install at least one Entra Private Network Connector to facilitate communication between Global Secure Access clients and on-premises resources. The Entra Private Network connector is a software agent that communicates outbound only. It requires no inbound connectivity, reducing public network exposure and minimizing the organization’s attack surface.

Entra Private Network Connector

The Entra Private Network connector is essentially the old Azure Application Proxy, updated to support all TCP and UDP-based communication. You can download the connector by opening the Entra admin center, navigating to Global Secure Access > Connect > Connectors, and clicking the Download connector service link.

Cloud Appliances

To enable access to cloud-hosted resources, the Entra Private Network connector can be installed on a VM in those environments. However, the Entra Private Network connector is also available as an appliance in public preview for the following cloud providers.

Resource Requirements

The following recommendations pertain to VM resources for the Entra Private Network connector server.

  • Windows Server 2016 or later. However, Windows Server 2016 reaches end of life in January 2027, so Windows Server 2022 and later are recommended. The Desktop edition is required, but it can technically be installed on Server Core with the Application Compatibility Feature on Demand for Server Core. However, Microsoft may not formally support this option.
  • Minimum 4 CPU cores and 8GB RAM. Monitor resource utilization during migration. Provision additional CPU and/or memory when utilization consistently exceeds 70% during peak times. Scaling out (adding servers) is preferred over scaling up (adding CPU and RAM).
  • Domain Join. Domain join is optional but recommended. Domain join is required to support single sign-on (SSO).

Connector Groups

A Connector Group is a logical grouping of Entra Private Network connectors. A Connector Group functions as a single unit for high availability and load balancing. Connectors are deployed in the same region as the tenant by default.

Default Group

When you install the Entra Private Network connector, it is placed into the Default connector group. However, this may not always be desirable. For example, the organization may have multiple data centers in different geographies. They may also have resources hosted in different Active Directory forests or perhaps located in isolated network locations. Using a common connector group may be suboptimal or not work at all.

Custom Groups

Administrators can define custom connector groups as needed. Custom connector groups ensure that connectors always have access to the resources nearest to them. They can be deployed in different locations and assigned to other Azure regions to ensure optimal traffic routing and reduced latency. Today, administrators can create connector groups in the North America, Europe, Australia, Asia, and Japan regions.

Create a Connector Group

Open the Microsoft Entra admin center and perform the following steps to create a new Entra Private Network connector group.

  1. Navigate to Global Secure Access > Connect > Connectors and Sensors.
  2. Click on New Connector Group.
  3. In the Name field, enter a descriptive name for the connector group.
  4. From the Connectors drop-down list, select one or more Entra Private Network connectors to assign to the group. Optionally, you can leave this field blank and assign connectors later.
  5. Click Save.

Connector Group Assignment

Once you have created a new connector group, you can assign Quick Access or individual Enterprise applications to it as follows.

Quick Access

To assign a new connector group to the Quick Access application, open the Entra admin console, navigate to Global Secure Access > Applications > Quick Access, and select the Network access properties tab. Select the new connector group from the Connector Group drop-down list.

Enterprise Applications

To assign a new connector group to an individual Enterprise application, navigate to Global Secure Access > Applications > Enterprise applications. Select an application, then select Network access properties. Select the new connector group from the Connector Group drop-down list.

Deployment Strategy

The following are best practices for deploying the Entra Private Network connector.

Redundancy

Always deploy at least two Entra Private Network connectors to ensure high availability and eliminate single points of failure.

Location

Install the Entra Private Network connector on servers closest to the applications they serve. Deploy connectors in all locations where applications are accessed, including on-premises networks and Infrastructure-as-a-Service (IaaS) resources.

Default Connector Group

Avoid using the default connector group for application assignment. Always use custom connector groups for application access. This ensures that new connectors do not process production traffic immediately after installation, which can cause unexpected behavior if the connector is not optimally deployed for the published resource or is not connected to the back-end application.

Deleting Connectors

Entra Private Network connectors cannot be removed from the management console. If you uninstall a connector, its status will show as inactive. After 10 days of inactivity, it will be automatically removed.

Reassigning Connectors

Administrators can reassign connectors to different connector groups at any time. However, existing connections on that connector server from the prior group assignment will remain until they age out. Administrators can restart the connector service or reboot the server to address this issue.

Restart-Service -Name WAPCSvc -PassThru

Connector Updates

The Entra Private Network connector will automatically install major updates when they become available. However, not all updates are applied automatically. Don’t be alarmed if you see discrepancies between release versions across multiple connector servers in the admin console. Administrators can always perform software updates manually to ensure uniform connector versions in their environment, if desired.

Diagnostics

Beginning with Entra Private Network connector v1.5.4287.0, the agent installation also includes the diagnostic utility ConnectorDiagnosticsTool.exe, which is in the C:\Program Files\Microsoft Entra Private Network Connector\ folder on the connector server. Running the tool initiates a series of tests to perform a health check of the connector service, including certificate status, connectivity, enabled TLS versions, service status, and more.

Note: Entra Private Network connector v1.5.4522.0 and later includes a graphical output, as shown above. Previous versions featured text-based output only.

Summary

Microsoft Entra Private Network Connectors are lightweight, outbound-only agents that enable secure access to on-premises and cloud resources through Entra Private Access. Best practices emphasize deploying at least two connectors per location for redundancy, placing them close to target applications, using custom connector groups for high availability, load balancing, and optimal routing, and assigning them to Quick Access or enterprise applications while avoiding the default group. Ensure that VMs are appropriately sized for the expected connector traffic, and consider using marketplace appliances for Azure, AWS, and GCP. If you’ve previously deployed the Entra Private Network connector, ensure that it is running the latest release to take advantage of new diagnostics for troubleshooting.

Additional Information

Microsoft Entra Private Network Connectors

Microsoft Entra Private Network Connector groups

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Access Intelligent Local Access

Leave a comment
by Richard M. Hicks on January 19, 2026  •  Permalink
Posted in Amazon Web Services, AWS, Azure, Azure App Proxy, Azure Application Proxy, cloud, Cloud Service, Deployment, Enterprise, enterprise mobility, Entra, Entra Global Secure Access, Entra ID, Entra Private Access, Entra Private Network Connector, Global Secure Access, GSA, Infrastructure, Microsoft, Microsoft Entra, Microsoft Entra Global Secure Access, Microsoft Entra ID, Microsoft Entra Private Access, Mobility, Private Network Connector, public cloud, Remote Access, SASE, Secure Access Service Edge, Secure Service Edge, Security, Security Service Edge, SSE, Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, Windows Server 2025, Zero Trust, Zero Trust Network Access
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 19, 2026

https://directaccess.richardhicks.com/2026/01/19/microsoft-entra-private-network-connector-overview-and-deployment-strategies/

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune

Leave a comment
by Richard M. Hicks on November 17, 2025  •  Permalink
Posted in Active Directory, Active Directory Certificate Services, AD CS, ADCS, administration, Always On VPN, AOVPN, authentication, Autopilot, Certificate Authentication, Certificate Authority, Certificate Connector for Intune, Certificate Services, Certificate-Based Authentication, certificates, Cloud PKI, Deployment, Device Management, device tunnel, Endpoint Manager, Enterprise, enterprise mobility, Entra ID, HAADJ, Hybrid Azure AD Join, Hybrid Entra ID Join, Hybrid Entra Join, Infrastructure, InTune, Intune Certificate Connector, Intune PFX Connector, MDM, MEM, MEMCM, Microsoft, Microsoft Endpoint Manager, Microsoft Entra, Microsoft Entra ID, Microsoft Intune, Mobile Device Management, Mobility, Operational Support, PFX Connector, PKCS, PKI, PowerShell, public key infrastructure, Remote Access, SCEP, Security, Simple Certificate Enrollment Protocol, systems management, troubleshooting, VPN, Windows 10, Windows 11
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on November 17, 2025

https://directaccess.richardhicks.com/2025/11/17/resolving-pkcs-certificate-mapping-issues-in-windows-autopilot-hybrid-join-deployments/

What’s New in Absolute Secure Access v14

Absolute Software recently announced a significant upgrade for its popular secure remote access and Zero Trust Network Access (ZTNA) solution. Version 14 of Secure Access introduces many compelling new features and updates that administrators will find beneficial. In addition, crucial security vulnerabilities in the previous release have been addressed.

New Features

Absolute Secure Access v14.x includes many enhancements over previous releases. Here are a few of the highlights.

Improved Performance

Absolute Secure Access v14 provides much faster throughput on multi-gigabit networks (e.g., 2.5Gbps Wi-Fi 6E/7 or 10Gbps wired). New kernel-level optimizations reduce CPU overhead by up to 40% on high-speed links, improving performance on faster networks.

Modern Certificate Handling

SHA-1 has been deprecated since 2011, and beginning with Absolute Secure Access v14, support for SHA-1 certificates has been removed completely.

Enhanced Client Auto Reconnect

Improved client auto-reconnect logic now survives Windows standby mode for more than 12 hours (previous versions were capped at around 4 hours). This will reduce frustration when devices return from standby for extended periods.

Automatic Host Group Updates

Host groups are an excellent way to streamline policy configuration for services like Microsoft 365 and AWS. These cloud providers publish the IP addresses of their services, which are dynamic and often change over time. Absolute Secure Access v14 now supports automatic host group updates for these services. Microsoft 365 updates occur every 28 days, and AWS updates occur every 5 days by default. This interval is configurable for administrators.

Security Updates

Absolute Secure Access v14 closes four server-side CVEs as well as 14 third-party CVEs (Apache, OpenSSL, etc.) that were not patched in v13.x.

Summary

If you have deployed previous versions of Absolute Secure Access, consider upgrading to v14.x today. You’ll gain improved performance, reduced administrative overhead, critical security updates, and much more. If you’d like help with your migration or want to learn more about the new capabilities in Absolute Secure Access v14, fill out the form below, and I’ll provide more information.

Additional Information

Absolute Secure Access

Absolute Secure Access Enterprise VPN Advanced Features In Depth

Absolute Secure Access and IPv6

Leave a comment
by Richard M. Hicks on November 5, 2025  •  Permalink
Posted in Absolute, Absolute Secure Access, Absolute Software, Enterprise, enterprise mobility, Mobility, NetMotion, NetMotion Mobility, NetMotion Software, Remote Access, Security, Security Update, Update, VPN
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on November 5, 2025

https://directaccess.richardhicks.com/2025/11/05/whats-new-in-absolute-secure-access-v14/

« Older Posts