All posts in category Zero Trust and SSE

What’s New in Entra Global Secure Access Client for Windows v2.34.222

On October 19, 2026, Microsoft announced an update for the Entra Global Secure Access (GSA) client. This latest release, v2.34.222, adds support for a new sign-in option, updates Conditional Access sign-in frequency, improves diagnostics, and enhances local network bypass. It also improves Windows Firewall behavior off network, along with telemetry and accessibility improvements.

Changes in v2.34.222

GSA client v2.34.222 includes the following new features and enhancements.

Web Sign-In

The GSA client now supports Web sign-in for Windows. This credential provider enables browser-based Windows sign-in using methods such as Microsoft Authenticator, Temporary Access Pass (TAP), or a SAML-P federated identity. Web sign-in requires a Microsoft Entra-joined device running Windows 11 version 22H2 with KB5030310 or later, plus internet connectivity.

Windows Firewall Profile

This release improves Windows Firewall profile selection when Private Access is enabled. When the device is not directly connected to the corporate network, Windows Firewall does not activate the Domain profile.

Traffic Forwarding Profile Details

The new GSA client features improved diagnostics. With this update, the Forwarding profile tab in the Advanced diagnostics section now displays the Traffic Forwarding Profile Name as it appears in the Entra admin center, along with the Traffic Forwarding Profile ID.

Traffic Forwarding Profile Name and ID

Conditional Access

GSA client v2.34.222 now includes support for Conditional Access sign-in frequency for Private Access applications. This feature is part of a phased rollout and might not be available in all tenants immediately.

Prefer Local Network Bypass

With this update, the Prefer local network option limits bypass to connections destined for IP addresses in common private network ranges. Microsoft documentation doesn’t elaborate on specifically which ‘common private network ranges’, but I suspect this means private IPv4 address ranges as defined in RFC 1918.

GSA Traceroute Changes

In GSA client v2.34.222, Microsoft has replaced the command-line version of the GSA traceroute tool (GsaTracert.exe) with a new GUI version. However, during my initial testing (and confirmed by others testing this feature), it appears to be broken at this time. When I launch GsaTracert.exe, the UI returns the following error message.

“Could not retrieve the forwarding profile from the registry. Ensure the Global Secure Access Client is installed and running.”

I will post an update as soon as Microsoft resolves this issue.

Additional Changes

In addition to the changes highlighted above, the new GSA client includes the following additional enhancements.

  • UDP tunneling improvements
  • Memory utilization improvements
  • New telemetry capabilities
  • Accessibility improvements
  • Bug fixes and other miscellaneous improvements

Summary

GSA client v2.34.222 introduces several useful enhancements for administrators and users. Organizations should validate the update against their existing configuration before broad deployment. My initial testing also identified an issue with the updated diagnostic tool, as described above.

Additional Information

Microsoft Entra Global Secure Access Client v2.34.222

Microsoft Entra Global Secure Access (GSA)

Microsoft Entra Private Access

Microsoft Entra Internet Access

Entra Private Access and VPN Migration Strategies on Entra.News

Leave a comment
by Richard M. Hicks on October 21, 2026  •  Permalink
Posted in Conditional Access, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on October 21, 2026

https://directaccess.richardhicks.com/2026/10/21/whats-new-in-entra-global-secure-access-client-for-windows-v2-34-222/

Microsoft Global Secure Access (GSA) Traffic Forwarding Profiles v2

Microsoft recently introduced custom Entra Private Access traffic forwarding profiles in public preview. Administrators can now provide different sets of private applications to selected users, groups, devices, and device platforms. This post explains how the profiles are assigned and prioritized, how to configure one, and how the new local network option handles overlapping address space.

Forwarding Profiles v1

Previously, organizations could assign the default Private Access traffic forwarding profile to selected users and groups, but they could not create separate Private Access profiles with different acquisition rules for different target groups. That made it difficult to give Windows devices one set of private application destinations and mobile devices another. Administrators could still control access through application assignments and Conditional Access, but the traffic the client acquired was less tailored to the user or device.

Forwarding Profiles v2

Global Secure Access (GSA) provides default traffic forwarding profiles for Microsoft traffic, Private Access, and Internet Access. Administrators can also create custom Private Access profiles and scope them to users, groups, devices, and device platforms. During the preview, a tenant can have up to 10 custom Private Access profiles.

Policy Processing

GSA evaluates traffic against the Microsoft, Private Access, and Internet Access profile types in that order. Traffic that matches none of them is not forwarded to the service. This order is separate from the priority used to choose between multiple applicable Private Access profiles.

Multiple Profiles

Each custom Private Access profile has its own acquisition rules, assignments, status, and priority. Assign a priority from 101 through 199. A lower number represents a higher priority. When more than one enabled Private Access profile applies to the same user and device, the client uses only the highest-priority applicable profile. The application rules from the other profiles are not combined with it.

Configure a Custom Private Access Profile

In the Microsoft Entra admin center, go to Global Secure Access > Connect > Traffic forwarding. Select Create new traffic forwarding profile, then Private access profile. Enter a descriptive name and, optionally, a description. Set a priority from 101 through 199 and choose whether the profile is enabled. Select Next, review the settings, and select Create. Note that the new profile has no acquisition rules or assignments until you configure them.

Acquisition Rules

Open the new profile and select Acquisition rules. Choose whether to include Quick Access destinations, then select the Private Access applications whose destinations the profile should acquire. Adding an application to a forwarding profile determines which traffic the client captures. Users must also be authorized to connect to the application’s resources.

Including Quick Access Destinations

Including Quick Access adds its configured destinations to the acquisition rules of this profile alongside the selected Private Access applications. This can provide a common set of destinations across custom profiles, but it does not change the Quick Access application’s configuration or grant users access to its resources. Confirm that the intended users are assigned to Quick Access as well as to the forwarding profile.

Assignments

Under Assignments, select View next to User and device assignments. Choose All users and devices or Selected users and devices, then save your selection.

Next, select View next to Device platform assignments and choose the supported platforms that should receive the profile. A device must match both assignment conditions. For example, selecting a user group and Windows limits the profile to Windows devices used by members of that group.

The new profile appears in the traffic forwarding list by priority, as shown here.

On an assigned client, open Advanced diagnostics > Forwarding profile to confirm that the expected Private Access application segments are present, as shown here.

Prefer Local Network

The Windows GSA client includes a Prefer local network option for cases where a local subnet overlaps with a configured private application destination. When an administrator enables the option, it appears in the client settings. A user can select it to keep applicable local subnet traffic on the local network, such as traffic to a printer or screen casting device, instead of having the client acquire that destination for Private Access. Microsoft introduced the option in Windows GSA client version 2.32.294.

The Problem It Solves

Overlapping private address space can make a local destination look like a destination defined in a Private Access application segment. For example, a user’s home printer and a corporate resource might both use 192.168.1.50. Prefer local network lets the user favor the directly connected local destination in this situation, such as when printing or screen casting.

Intelligent Local Access

Intelligent Local Access (ILA) serves a different purpose. It uses configured DNS probes to identify a corporate private network and can then send traffic directly to specified Private Access applications available on that network. Prefer local network addresses when there is an overlap between the device’s local subnet and a Private Access destination, such as a printer on a home network. ILA depends on a matching configured private network and application. An address overlap alone does not trigger it.

Summary

Custom Private Access traffic forwarding profiles give administrators more control over which private application destinations the Global Secure Access (GSA) client acquires for different users and devices. Assignments determine who receives a profile, while priority determines which profile applies when assignments overlap. The Prefer local network option also helps Windows users reach local devices when their subnet overlaps a Private Access destination.

Additional Information

Global Secure Access traffic forwarding profiles

Create a Private Access traffic forwarding profile

Entra Private Access Intelligent Local Access

Leave a comment
by Richard M. Hicks on September 29, 2026  •  Permalink
Posted in Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on September 29, 2026

https://directaccess.richardhicks.com/2026/09/29/microsoft-global-secure-access-gsa-traffic-forwarding-profiles-v2/

Live! 360 Event Orlando, Florida 2026

I’m excited to announce that I’ll be attending the upcoming Live! 360 Event, November 15-20, 2026, at Royal Pacific Resort at Universal Orlando, Florida. I’ll be in attendance all week and will be delivering a few talks at the event this year.

Sessions

I’ll be presenting two sessions at this year’s event. They are:

Join Me!

If you are planning to attend the event, please join my sessions! I will be at the conference center all week, so don’t hesitate to reach out and contact me while you are there. I’m looking forward to seeing everyone soon!

Leave a comment
by Richard M. Hicks on September 17, 2026  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, Cloud PKI, Entra Global Secure Access, Entra Private Access, Load Balancing, PKI, Training and Events, Windows Server, Zero Trust and SSE
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on September 17, 2026

https://directaccess.richardhicks.com/2026/09/17/live-360-event-orlando-florida-2026/

Entra Private Network Connector Session Persistence

The Microsoft Entra Private Network Connector is a lightweight on-premises software agent that enables Microsoft Entra Private Access to forward Global Secure Access (GSA) client traffic to internal resources. In environments with multiple connectors, traffic is normally distributed across available connectors in a connector group. While this improves resiliency and load distribution, it can create challenges for applications that rely on a consistent connector source IP address.

Stateless Connectors

By default, requests are distributed randomly among the available connectors in a connector group. Traffic forwarded to the internal resource uses the connector server’s IP address as its source. Consequently, separate connections from the same user and device can reach the application through different connectors. Importantly, session state is not shared among connectors in a connector group. As such, applications that associate session state with the source IP address may reject or interrupt these connections.

Why Session Persistence Matters

In some scenarios, an internal application might allow access only from specific connector IP addresses or associate an authenticated session with the source IP address. Random connector selection can cause subsequent connections to arrive from a different address, potentially interrupting the session. Session persistence reduces this risk by consistently using the same connector for the user and device.

Session Persistence

Microsoft recently introduced session persistence for Entra Private Access applications. When enabled, requests from the same user and device are consistently routed to the same connector for the duration of the session. This helps maintain a consistent connector egress IP address for applications that depend on source IP addresses for authentication, authorization, or session management.

Traffic Routing

The connector traffic routing method is configured on a per-application basis. Traffic routing methods can be defined on Quick Access or Enterprise applications, and the setting can be configured on the Network access properties tab. Administrators have two options: Random or Session Persistence.

Random

This is the default behavior for the Private Network connector. All new connections are distributed randomly among connectors in the connector group.

Session Persistence

Selecting the Session Persistence option consistently routes requests from the same user and device to the connector on which the session was established.

Connector Routing Method Comparison

The following table summarizes these configuration options.

Routing MethodBenefitsConsiderations
RandomBetter distribution across connectors in a connector groupSource IP address may change between connections
Session PersistenceConsistent connector egress IP addressMay not distribute sessions as evenly as the Random method

Failover

If the preferred connector becomes unavailable, subsequent traffic may be routed through another available connector. Applications that depend on the connector’s source IP address might require the user to establish a new session.

GSA Applications Only

Session persistence applies only to Global Secure Access applications. It is not supported for applications published using Microsoft Entra Application Proxy.

Summary

By default, Microsoft Entra Private Access distributes requests randomly among available connectors. Although this provides load distribution, it can create problems for applications that depend on a consistent connector source IP address. Session persistence addresses this issue by consistently routing traffic from the same user and device through the same connector for the duration of the session. This feature applies only to Global Secure Access applications and is not supported for Microsoft Entra Application Proxy applications.

Additional Information

Entra Private Network Connector Overview and Deployment Strategies

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Network Connector Groups

Leave a comment
by Richard M. Hicks on September 4, 2026  •  Permalink
Posted in Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Zero Trust and SSE
Tagged , , , , , , ,

Posted by Richard M. Hicks on September 4, 2026

https://directaccess.richardhicks.com/2026/09/04/entra-private-network-connector-session-persistence/

Entra Global Secure Access (GSA) Client Intune Deployment PowerShell Script

The Microsoft Entra Global Secure Access (GSA) client is commonly deployed using Microsoft Intune. To deploy the client as an Intune Win32 app, administrators package the installer and a PowerShell installation script into an .intunewin file. Microsoft provides a sample PowerShell script that creates a log, configures Windows to prefer IPv4 over IPv6, and launches the installer. However, the sample has several limitations that can make it unreliable in production environments. To address these shortcomings, I’ve refactored the code to make it more robust and better aligned with enterprise deployment best practices.

Script Improvements

Microsoft’s PowerShell script for installing the GSA client has several significant limitations. My refactored version includes the following improvements.

  1. Preserved the existing DisabledComponents setting. Microsoft’s example overwrites the entire registry value, potentially removing previously configured settings. My version sets the 0x20 bit to prefer IPv4 while preserving any other flags already present.
  2. Validates the installer’s Authenticode signature. My revised script verifies that the installer has a valid Authenticode signature and that the signing certificate identifies Microsoft Corporation as the publisher.
  3. Preserves the pending reboot state. My script records when the registry setting was changed and compares that timestamp with the device’s last boot time. If the device has not restarted, subsequent runs continue to return exit code 3010, even if an earlier installation attempt failed.
  4. Expanded exit-code handling. The script writes a timestamped PowerShell transcript to the Intune Management Extension log directory, allowing it to be included with collected Intune diagnostics. Logging failures do not prevent the installation from continuing.
  5. Intune-integrated logging. I’ve updated the script’s logging to use the Intune Management Extensions logs folder, so logs are captured by Intune’s diagnostics collection. Each run of the script generates its own timestamped log file, making troubleshooting easier. Also, logging failures never block installation.
  6. Best practice alignment. I’ve added comment-based help, culture-invariant timestamps, and a $PSScriptRoot guard with a clean error to handle script execution issues. In addition, the script is digitally signed to support environments that enforce signed-script execution policies.

GitHub

I’ve published my refactored GSA client installation script on GitHub. You can download the script here:

https://github.com/richardhicks/gsa/blob/main/Install-GSAClient.ps1

Note: The script expects the installer to be named GlobalSecureAccessInstaller.exe. However, downloaded installers typically include the version number in the filename, such as GlobalSecureAccessInstaller_<version>.exe. Before creating the .intunewin package, either rename the installer or update the $InstallerName variable in the script.

Contribute

Suggestions and contributions are welcome. If you have ideas for making the GSA client deployment more robust or reliable, please submit a pull request on GitHub.

Summary

Microsoft provides a PowerShell script to deploy the Entra GSA client via Intune, but it has several limitations. This refactored version preserves existing registry settings, validates the installer, improves reboot and exit-code handling, integrates logging with Intune diagnostics, and better aligns with enterprise deployment best practices.

Additional Information

Install-GSAClient.ps1 PowerShell Script on GitHub

Prepare Win32 App Content for Upload to Microsoft Intune

Install the Global Secure Access Client for Microsoft Windows

Leave a comment
by Richard M. Hicks on August 31, 2026  •  Permalink
Posted in Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Microsoft Intune, PowerShell, Zero Trust and SSE
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on August 31, 2026

https://directaccess.richardhicks.com/2026/08/31/entra-global-secure-access-gsa-client-intune-deployment-powershell-script/

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

On August 26, 2026, Microsoft released version 2.32.294 of the Entra Global Secure Access (GSA) client. This release addresses challenges caused by overlapping local and private network address spaces, improves tunnel creation performance, and prepares the client to receive future upgrades through Windows Update.

Changes in v2.32.294

GSA client v2.32.294 includes the following new features and capabilities.

Prefer Local Network

The Prefer Local Network option allows users to access resources on their current local network when its address space overlaps with a private application’s subnet. Common scenarios include accessing a local printer or casting to a nearby device.

Support for Prefer Local Network is included in this client release. However, the administrative setting required to expose the option to users is not yet available in the traffic forwarding profile. Once Microsoft makes this setting available, administrators can enable the feature and allow users to turn it on when needed.

Windows Update

Beginning in November 2026, the GSA client will automatically receive upgrades through Windows Update. Endpoints must be running GSA client 2.31.125 or later (2.32.294 or later for Windows on Arm).

Administrators can opt out of automatic updates when installing or upgrading the GSA client using the following command.

GlobalSecureAccessInstaller.exe /quiet /norestart EnableWindowsUpdates=0

Additional Enhancements

GSA client v2.32.294 accelerates the creation of new tunnels, improving connection performance. The installer also includes .NET Runtime 10.0.9. Additional changes include telemetry and accessibility enhancements, the removal of LastMile for Office 365 telemetry, and miscellaneous bug fixes.

Summary

Global Secure Access client v2.32.294 introduces useful improvements for users working on networks with overlapping address spaces and lays the groundwork for automatic client upgrades through Windows Update. The release also improves tunnel creation performance and includes several updates to telemetry, accessibility, runtime, and reliability. Administrators should evaluate Windows Update behavior and determine whether automatic upgrades are appropriate for their deployment and change management requirements.

Additional Information

Microsoft Entra Global Secure Access (GSA) Client v2.32.294.0

Microsoft Entra Global Secure Access (GSA)

Microsoft Entra Private Access

Microsoft Entra Internet Access

Entra Private Access and VPN Migration Strategies on Entra.News

Leave a comment
by Richard M. Hicks on August 27, 2026  •  Permalink
Posted in Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Security Updates, Zero Trust and SSE
Tagged , , , , , , , , , , ,

Posted by Richard M. Hicks on August 27, 2026

https://directaccess.richardhicks.com/2026/08/27/whats-new-in-entra-global-secure-access-client-v2-32-294-0/

Entra Internet Access TLS Inspection and Always On VPN: Troubleshooting SSTP Connection Failures

Microsoft Entra Global Secure Access (GSA) is a cloud-based Security Service Edge (SSE) solution that includes Entra Private Access to provide zero-trust network access to private data and applications, and Entra Internet Access to provide security controls for general internet access. Entra Internet Access includes features such as web content filtering, AI prompt controls, TLS inspection, and more. Entra Private Access and Entra Internet Access share a common client: the Global Secure Access Client.

TLS Inspection

TLS inspection is a powerful feature of Entra Internet Access that allows inspection and policy enforcement for encrypted internet traffic. It enables more thorough inspection and is required for features such as AI prompt policies. When TLS inspection is enabled, the TLS connection from the target server (origin server) is terminated by the Entra service. A new session is created between the cloud and the endpoint using a dynamically generated TLS certificate issued by Entra. As Entra holds the private key for this certificate, it can decrypt and inspect traffic as necessary.

Always On VPN

Recently, a customer asked me to help troubleshoot an Always On VPN user tunnel connectivity issue. The problem began shortly after deploying the Global Secure Access client with TLS inspection enabled. Administrators had configured the default TLS inspection policy to inspect traffic for all websites.

User Tunnel Failures

Attempts to manually start the Always On VPN user tunnel resulted in a failed connection attempt with the following error message.

Error 0x800704D4: The network connection was aborted by the local system.

Event Logs

Reviewing the client event logs revealed numerous Event ID 20227 entries from the RasClient source with the following error message.

The user DOMAIN\User dialed a connection named [connection name] which has failed. The error code returned on failure is -2147023660.

Note: Error code -2147023660 is the decimal equivalent of 0x800704D4.

Troubleshooting

Initial testing with Test-NetConnection confirmed that TCP port 443 on the VPN server was reachable. However, using Get-TlsCertificate revealed the real problem.

Although the certificate subject matched the VPN server, the issuer did not. Instead of the VPN server’s issuing CA, the certificate had been issued by Microsoft Entra Global Secure Access, confirming that TLS inspection was intercepting the connection.

SSTP and TLS Inspection

The Secure Socket Tunneling Protocol (SSTP) is a Microsoft proprietary VPN transport that uses HTTP for tunneling and TLS for security. Unlike a web browser, which can establish a new trusted TLS session with an inspection proxy, SSTP validates the VPN server’s certificate as part of establishing the VPN tunnel. Any certificate substitution, even by a trusted TLS inspection service, changes the server certificate thumbprint and causes SSTP validation to fail.

Workaround

The solution is to create a TLS inspection exclusion policy to exempt inspection for the VPN server FQDN(s), as shown here.

Summary

Microsoft Entra Internet Access TLS inspection can unintentionally interfere with Always On VPN deployments that use SSTP. Because TLS inspection replaces the VPN server’s certificate with one issued by Microsoft Entra, SSTP detects the certificate mismatch and terminates the connection. If you use Always On VPN with Entra Internet Access, configure a TLS inspection exclusion for your VPN server FQDNs to prevent interception while preserving TLS inspection for general internet traffic.

Additional Information

Always On VPN vs. Entra Private Access: Choosing the Right Access Model for your Organization

What is Microsoft Entra Global Secure Access?

Microsoft Entra Internet Access

Microsoft Entra Private Access

Always On VPN SSTP and 47-Day TLS Certificates

Always On VPN SSTP and HSTS

Leave a comment
by Richard M. Hicks on July 22, 2026  •  Permalink
Posted in Always On VPN, Azure and AWS, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, PKI, TLS, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on July 22, 2026

https://directaccess.richardhicks.com/2026/07/22/entra-internet-access-tls-inspection-and-always-on-vpn-troubleshooting-sstp-connection-failures/

Entra Internet Access TLS Inspection Fails with ERR_CERT_INVALID

Microsoft Entra Internet Access is a powerful cloud-based Secure Web Gateway (SWG) feature within the Entra Global Secure Access (GSA) Security Service Edge (SSE) solution. Entra Internet Access provides Zero Trust, identity-aware access to internet resources, private web-based applications, and Microsoft 365, with full integration with Entra Conditional Access.

TLS Inspection

Entra Internet Access includes an optional TLS Inspection feature that allows the GSA client to decrypt HTTPS traffic, inspect for threats, identify policy violations, and enforce Data Loss Prevention (DLP) policies. Importantly, enabling TLS inspection for GSA allows administrators to apply prompt injection protection policies to control the usage of generative AI applications.

TLS Inspection Certificate

Before enabling TLS inspection for Entra Internet Access, administrators must first create a TLS inspection certificate. This certificate must be signed by a trusted certification authority (CA). The process is simple and straightforward, and well-documented here.

Invalid Certificate Error

After enabling Entra Internet Access TLS inspection, administrators may find that all websites subject to TLS inspection are inaccessible. The browser displays the following error message:

Your connection isn’t private
Attackers might be trying to steal your information from <website> (for example, passwords, messages, or credit cards.)

NET:ERR_CERT_INVALID

Clicking on the Advanced button shows the following additional information:

<website> uses encryption to protect your information. When Microsoft Edge tried to connect to <website> this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be <website>, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Microsoft Edge stopped the connection before any data was exchanged.

You can’t visit <website> right now because the website sent scrambled credentials that Microsoft Edge can’t process. Network errors and attacks are usually temporary, so this page will probably work later.

Root Cause (Pun Intended!)

This issue can be caused by restrictions placed on the root CA. Specifically, if the root CA certificate includes a policy that restricts the CA path length (the number of subordinate CAs allowed downstream), the Microsoft Global Secure Access Intermediate CA, which issues certificates for TLS-inspected websites, cannot be validated successfully.

In this example, the root CA certificate includes a basic constraint that defines a maximum of 1 intermediate CA in the chain. Crucially, the extension is marked as Critical, so it must be enforced.

Because the root CA enforces a path length constraint of 1, the TLS inspection subordinate CA can exist beneath it, but no additional subordinate CA certificates are permitted. As a result, the Microsoft Global Secure Access Intermediate CA exceeds the allowed chain depth, causing certificate validation to fail.

Resolution

The fix for this issue is simple, yet complex. The root CA certificate must be renewed, this time without enforcing the CA path length policy. To do this, open an elevated command window on the root CA and run the following command.

certutil.exe -setreg policy\capathlength 0xffffffff

Important: If your CA hierarchy uses CAPolicy.inf to define the CAPathLength setting, update the file before renewing the CA certificate.

Next, restart the CA service for the change to take effect.

Restart-Service CertSvc -PassThru

Finally, renew the CA certificate.

certutil.exe -f -renewcert ReuseKeys

Restart the CA service once more for the change to take effect.

Restart-Service CertSvc -PassThru

Once complete, distribute the new root CA certificate to Active Directory and to Intune-managed endpoints using a Trusted Certificate device configuration policy.

Finally, configure a new Entra TLS inspection certificate in the Entra admin center to replace the old one, signed with the updated root CA certificate. Once the certificate has been uploaded, ensure it is enabled.

Important: Renewing a root CA certificate can be highly disruptive. Proceed with caution in production environments. Ensure that all enterprise assets receive the new root CA certificate in a timely manner. Alternatively, to reduce the chance of disruption, consider deploying a new root CA dedicated to Entra TLS inspection.

Result

Once these changes are made, the certificate chain will allow the Microsoft Global Secure Access Intermediate CA to exist beneath the TLS inspection CA, resulting in a valid certificate chain for TLS-inspected websites. Browsers will once again trust the dynamically generated certificates, eliminating the ERR_CERT_INVALID error.

The following certificate chain shows the corrected configuration after renewing the root CA certificate and recreating the TLS inspection certificate.

Summary

Entra Internet Access TLS inspection relies on a certificate chain that includes the Microsoft Global Secure Access Intermediate CA. If the root CA that signs the TLS inspection certificate enforces a restrictive path length constraint, certificate validation can fail, causing browsers to display ERR_CERT_INVALID errors for all TLS-inspected websites. Reviewing the certificate chain and understanding how basic constraints affect subordinate CAs can help quickly identify and resolve this issue. When deploying TLS inspection, ensure that CA hierarchy restrictions are compatible with this deployment scenario. Consider using a dedicated PKI hierarchy to minimize operational impact.

Additional Information

Tutorial: Enable Entra Internet Access TLS Inspection

Protect Enterprise Generative AI Applications with Prompt Injection Protection

Leave a comment
by Richard M. Hicks on June 16, 2026  •  Permalink
Posted in Always On VPN, Azure and AWS, Conditional Access, Entra Global Secure Access, Entra ID, Entra Internet Access, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on June 16, 2026

https://directaccess.richardhicks.com/2026/06/16/entra-internet-access-tls-inspection-fails-with-err_cert_invalid/

What’s New in Entra Private Network Connector v1.5.4892.0

An important update is available for the Microsoft Entra Private Network Connector. The Entra Private Network Connector is used to publish on-premises web applications to the internet. It is also used for Global Secure Access (GSA) with Entra Private Access, allowing GSA clients to access on-premises resources. Entra Private Network Connector v1.5.4892.0 includes important new functionality to streamline troubleshooting and improve stability and performance.

New Features

The Entra Private Network Connector v1.5.4892.0 now includes a diagnostic tool on the system tray. This gives administrators a visual indicator of connector status and provides quick access to diagnostics and log files.

Diagnostics

Right-clicking the connector and choosing ‘Connector diagnostics’ launches the Connector Diagnostics window. Here you’ll find three tabs: Overview, Health Check, and Advanced Logs.

Overview

The Overview tab provides details about the connector, such as the Tenant ID, Connector ID, version, supported TLS versions, the connector server’s IPv4 address (IPv6 information is not displayed), the server’s hostname, and the operating system version.

Health Check

Clicking on the Health Check tab will perform a comprehensive system health check. Status information for each check is provided, indicating whether it is Passed or Failed. Optionally, administrators can export the report in text, HTML, or JSON format for further analysis. Each health check can be expanded to reveal additional information about the individual check.

Advanced Logs

Clicking the Advanced Logs tab allows administrators to retrieve detailed log information. Session channel logging is enabled by default but can optionally be disabled if needed. You can choose specific start and end dates and times to collect logs, then click Retrieve Logs to collect them.

Once complete, it’s not immediately obvious where to find these logs. Clicking the Logs Retrieved button prompts the administrator to select a location in which to save the log files.

Improvements

This update improves the reliability of name resolution by filtering invalid DNS responses. In addition, the update improves connector logging to the Windows Event Log and fixes various issues and bugs.

Updating to v1.5.4892.0

Existing Entra Private Network Connector installations will not automatically receive this update. Administrators must manually download the connector from the Microsoft Entra admin center and apply the update themselves to take advantage of these new features and capabilities.

Additional Information

Microsoft Entra Private Network Connector v1.5.4892.0

Microsoft Entra Private Network Connector Overview and Deployment Strategies

Preventing Port Exhaustion on Entra Private Network Connector Servers

Leave a comment
by Richard M. Hicks on June 15, 2026  •  Permalink
Posted in Entra Global Secure Access, Entra ID, Entra Private Access, Windows Server, Zero Trust and SSE
Tagged , , , , , ,

Posted by Richard M. Hicks on June 15, 2026

https://directaccess.richardhicks.com/2026/06/15/whats-new-in-entra-private-network-connector-v1-5-4892-0/

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

On June 2, 2026, Microsoft released version 2.31.125 of the Entra Global Secure Access (GSA) client. This update introduces several enhancements designed to improve client resiliency, simplify troubleshooting, and provide administrators with better visibility into network connection status.

Changes in v2.31.125

GSA client v2.31.125 includes new features to streamline connectivity troubleshooting.

Network Status

The new GSA client can now distinguish between a complete network disconnection and a scenario where the device remains connected to a local network but lacks internet access. This distinction helps administrators and users more quickly identify the source of connectivity issues and reduce troubleshooting time.

Network Disconnected

No Internet Connectivity

Local Access

When Intelligent Local Access (ILA) is enabled, the client now clearly indicates when a device is connected to a trusted private network. This provides additional visibility into ILA decision-making and helps confirm that local access policies are functioning as expected.

Sign Out

The new GSA client includes an account picker when a user signs out on Entra-registered or Entra-joined devices. This enhancement simplifies account management on shared or multi-user devices by allowing users to switch identities without fully reinstalling or reconfiguring the client.

The sign out option is disabled by default. It must be enabled by setting the following registry key.

HKLM\Software\Microsoft\Global Secure Access Client\HideSignOutButton DWORD = 0

User Session Detection

Because the GSA client supports only a single interactive Windows session, this new indicator helps quickly identify unsupported multi-session scenarios that may impact client functionality or troubleshooting efforts.

Other Changes

In addition to the new features and capabilities outlined above, these changes are also included.

  • Updated embedded .NET Runtime to version 8.0.26.
  • GSA Forwarding Profile Service now automatically restarts after a failure.
  • Improved detection and tunneling of agentic network connections.
  • Various bug fixes and performance improvements.

Summary

GSA Client v2.31.125 introduces several useful enhancements focused on troubleshooting, resiliency, and user experience. Improved network status visibility, Intelligent Local Access awareness, account sign-out support, and enhanced session detection provide administrators with better diagnostic capabilities while making the client easier for end users to understand and manage. Although this release remains in preview, administrators are encouraged to begin testing this latest release soon.

Additional Information

Microsoft Entra Global Secure Access (GSA) Client v2.31.125

Microsoft Entra Private Access Intelligent Local Access

Leave a comment
by Richard M. Hicks on June 4, 2026  •  Permalink
Posted in Absolute Secure Access, Azure and AWS, Entra Global Secure Access, Entra ID, Entra Internet Access, Entra Private Access, Microsoft Intune, Zero Trust and SSE
Tagged , , , , , , , ,

Posted by Richard M. Hicks on June 4, 2026

https://directaccess.richardhicks.com/2026/06/04/whats-new-in-entra-global-secure-access-client-v2-31-125/

« Older Posts