All posts in category Entra ID

What’s New in Entra Global Secure Access Client v2.24.117

In early December 2025, Microsoft announced an update for the Entra Global Secure Access client. This latest release, v2.24.117, includes important changes that administrators will find helpful for efficient connectivity and enhanced troubleshooting.

Intelligent Local Access

The latest release of the Microsoft Entra Global Secure Access client adds support for Intelligent Local Access (ILA). ILA ensures optimal network connectivity when accessing published resources. ILA can detect when it is on a trusted network and send traffic directly to the resource, bypassing the cloud gateway to improve performance. Authentication and authorization are still required for application access regardless of location.

B2B Guest Access

B2B Guest Access, now in public preview, enables external partners to securely access an organization’s private resources using their own devices and home Microsoft Entra ID credentials, without credential duplication. Partners install the Global Secure Access client, sign in, and switch to the resource tenant, routing traffic via Private Access profiles for Conditional Access, MFA, and continuous evaluation. It supports BYOD and multitenant switching, requires guest user setup and specific client configurations in the resource tenant, and needs licensing only in the resource tenant. However, B2B Guest Access does not support Kerberos-based on-premises resources. More details here.

Traceroute

This latest release of the Entra Global Secure Access client also includes a new traceroute tool. GsaTracert.exe, located in the C:\Program Files\Global Secure Access Client\GSATracert\ folder, allows administrators to test connectivity to published resources and evaluate network response time and performance.

FQDN

Administrators can use GsaTracert.exe to validate connectivity to a resource using its fully qualified domain name (FQDN). When running the command, GsaTracert.exe reports the round-trip time (RTT) in milliseconds for each hop along the path, including the target resource. It will also indicate which point of presence (PoP) the client is currently connected to. The syntax to perform this test is:

.\GsaTracert.exe --host <fqdn:port>

For example:

.\GsaTracert.exe --host app1.lab.richardhicks.net:443

IP:Host

In addition to testing an FQDN, administrators can test individual resources using a combination of IP address and port number. The syntax to perform this test is:

.\GsaTracert.exe --host <ip:port>

For example:

.\GsaTracert.exe --host 172.16.0.254:22

Application ID

In addition to FQDN and IP:Port, administrators can also supply the application ID to test. However, since an application can include multiple IP addresses and/or ports, the measurement for backend resources is omitted when using this option. The syntax to perform this test is:

.\GsaTracert.exe --app-id <app ID>

For example:

.\GsaTracert.exe --app-id a8b914b-4143-4901-9fbb-09b61319d5a6

Note: You can find the application ID for a published application by opening the Entra admin center and navigating to Global Secure Access > Applications > Enterprise Applications. The application ID will be displayed on the Overview page of the published Enterprise application.

Speedtest

Administrators can use the –speedtest switch with any of the combinations above to test the endpoint’s Internet performance. The results are for the connection to the public Internet, not to the published resource.

Additional Features

The following new features are designed to improve the user experience for Global Secure Access users.

Disable Private Access

Administrators can now use a registry setting to show the Disable button, allowing users to disable Entra Private Access. Disabling Private Access is helpful when a device is on the internal network, and the user prefers to access resources directly rather than through Global Secure Access.

View Account

The new Global Secure Access client now includes a View Account link to the user’s Microsoft Entra My Account website.

Summary

The Microsoft Entra Global Secure Access Client v2.24.117 introduces several valuable enhancements for administrators and users alike. Key highlights include Intelligent Local Access for optimized performance on trusted networks, public preview support for B2B Guest Access enabling secure external collaboration without credential duplication, and the new GsaTracert.exe traceroute tool for detailed network diagnostics. Additional improvements, such as the ability to disable Private Access via registry settings and quick access to the My Account portal, further streamline management and troubleshooting. These updates reinforce Microsoft Entra Global Secure Access as a robust solution for secure, efficient resource connectivity.

Additional Information

Microsoft Entra Global Secure Access client v.2.24.117

Install the Entra Global Secure Access client for Microsoft Windows

Microsoft Entra Private Access Intelligent Local Access (ILA)

Preventing Port Exhaustion on Entra Private Network Connector Servers

Leave a comment
by Richard M. Hicks on January 5, 2026  •  Permalink
Posted in Entra, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Global Secure Access, GSA, Microsoft, Microsoft Entra, Microsoft Entra Global Secure Access, Microsoft Entra ID, Microsoft Entra Internet Access, Microsoft Entra Private Access, Security, Security Service Edge, SSE, Windows 10, Windows 11, Zero Trust, Zero Trust Network Access, ZTNA
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 5, 2026

https://directaccess.richardhicks.com/2026/01/05/whats-new-in-entra-global-secure-access-client-v2-24-117/

Entra Private Access Intelligent Local Access

Microsoft Entra Private Access, part of the Microsoft Global Secure Access (GSA) Security Service Edge (SSE), is a compelling new cloud-based Zero Trust Network Access (ZTNA) solution that offers enhanced security compared to traditional VPNs. Until recently, traffic for all defined applications flowed through the GSA tunnel regardless of the client’s location. This resulted in sub-optimal traffic flow when the client is on the same network as resources defined in Quick Access or Enterprise applications. Fortunately, Microsoft has introduced a new feature to address this crucial limitation.

Intelligent Local Access

Historically, DirectAccess used the Network Location Server (NLS) to determine network location. Always On VPN used Trusted Network Detection (TND) to accomplish this same task. GSA has lacked this critical feature since its initial release. Thankfully, Microsoft recently added Intelligent Local Access (ILA). This feature allows GSA to identify a trusted private network and bypass the client, routing traffic directly to the local resource.

How It Works

With GSA ILA, administrators define a Private Network in their GSA configuration. Administrators define a resource by FQDN along with DNS servers to use for name resolution. When the client resolves this FQDN to a matching IP address (CIDR or IP address range is accepted as well), the client will then bypass GSA for target resources defined in the policy.

Note: Authentication is still performed for access to GSA applications even when ILA indicates the client is on a private network. However, after successful authentication and the client satisfies any conditional access policies, traffic is forwarded directly to the resource rather than routed through the GSA tunnel.

Configure ILA

To configure ILA, open the Microsoft Entra admin center and follow these steps.

  1. Navigate to Global Secure Access > Connect > Private Networks.
  2. Select Add Private Network.
  3. Enter a name for the trusted network in the Name field.
  4. Enter the IPv4 address(es) of any DNS server(s) used for this network in the DNS servers field.
  5. Enter the fully qualified domain name (FQDN) of a resource on this network for name resolution in the Fully qualified domain name field (see below for additional information).
  6. Select an option from the Resolved to IP address type drop-down list. Options include IP address, IP address range (CIDR), and IP address range (IP to IP).
  7. Enter the expected name resolution result in the Resolved to IP address value field.
  8. Click Select applications below Target resource to exclude from GSA processing when on this network.
  9. Click Create.

ILA FQDN Recommendation

Technically speaking, the FQDN used by GSA for ILA can be any internal resource, even those included in Quick Access or Enterprise applications. Since the GSA client only attempts to resolve this name and doesn’t connect to it, administrators should configure a dedicated static DNS record with a dummy IP address for this purpose. A static DNS record ensures it won’t be overwritten, scavenged, or accidentally deleted. For example, administrators can create a DNS A record named ‘ILA’ that resolves to any IP address they choose, as long as it matches the IP address defined in the Private network configuration for GSA.

Troubleshooting

When confirming GSA client traffic bypass, using standard network troubleshooting tools isn’t sufficient. Here are a few examples.

Resolve-DnsName

Although the client is on a private network, Resolve-DnsName shows the IP address of the GSA address range of 6.6.x.x.

Ping (ICMP)

Interestingly, if you try to ping the FQDN, you’ll see that traffic bypasses the GSA client, as the response comes from the destination’s address.

By contrast, attempts to ping the FQDN outside the private network fail as the GSA client does not pass ICMP.

Advanced Diagnostics

The best way to confirm GSA client traffic bypass for private network resources is to use the Advanced diagnostics tool included with the GSA client. Click the GSA client icon in the notification area, then follow these steps to validate GSA client bypass when ILA is detected.

  1. Select the Troubleshooting tab in the navigation tree.
  2. Click Run Tool in the Advanced diagnostics tool section.
  3. Select the Traffic tab.
  4. Remove the Action == Tunnel filter.
  5. Click Start collecting.
  6. Initiate traffic to a Quick Access or Enterprise application configured for bypass when ILA detects a private network.
  7. Click Stop collecting.
  8. Review the log and note the Connection status for the traffic generated previously. It should indicate Bypassed when ILA detects a private network, as shown here.

Summary

With Intelligent Local Access now a feature of the Global Secure Access client, administrators can configure the client to bypass the GSA tunnel and access Quick Access and Enterprise applications directly for better performance, while still enforcing authentication and Conditional Access.

Additional Information

Enable Intelligent Local Access in Microsoft Entra Private Access

Entra Private Access Channels are Unreachable

1 Comment
by Richard M. Hicks on December 1, 2025  •  Permalink
Posted in Azure Active Directory, Azure AD, Entra, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Entra Private Network Connector, Global Secure Access, GSA, ILA, Intelligent Local Access, Microsoft, Microsoft Entra, Microsoft Entra Global Secure Access, Microsoft Entra ID, Microsoft Entra Internet Access, Microsoft Entra Private Access, Secure Access Service Edge, Secure Service Edge, Security, Security Service Edge, SSE, TND, troubleshooting, Trusted Network Detection, Windows 10, Windows 11, Zero Trust, Zero Trust Network Access
Tagged , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 1, 2025

https://directaccess.richardhicks.com/2025/12/01/entra-private-access-intelligent-local-access/

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/

« Older Posts