Microsoft Entra Global Secure Access: The Ultimate Step-by-Step Troubleshooting Guide for Zero Trust Warriors + Video

By /

Listen to this Post

Featured Image

Introduction:

Microsoft Entra Global Secure Access (GSA) is a cornerstone of Zero Trust network access, funneling traffic through Identity-Aware Proxies and Conditional Access policies. However, when GSA fails—whether from misconfigured DNS, stale Primary Refresh Tokens (PRT), or broken traffic forwarding profiles—troubleshooting becomes a layered puzzle. This guide delivers a structured, command‑heavy methodology to isolate and resolve client‑side, proxy, and authentication issues in Entra GSA.

Learning Objectives:

  • Validate client health, service status, DNS resolution, and endpoint connectivity for GSA tunnels
  • Diagnose and refresh traffic forwarding profiles, device PRT state, and proxy settings on Windows/Linux
  • Leverage Advanced Diagnostics, entra logs, and sign‑in telemetry to pinpoint policy failures

1. Validate Client Health, Service State, and DNS

Start by confirming the Microsoft Entra GSA client is installed, running, and reaching the correct endpoints.

Windows (PowerShell as Admin):

Get-Service -Name "GlobalSecureAccess" | Select Name, Status, StartType
 Should show Status = Running
Test-NetConnection globalconnectivity.azure.com -Port 443
Resolve-DnsName gsaclient.azureedge.net

Linux (systemd distribution):

systemctl status global-connect-agent
curl -v https://globalconnectivity.azure.com/health
nslookup gsaclient.azureedge.net

Step‑by‑step guide:

  1. Verify the `GlobalSecureAccess` service (Windows) or `global-connect-agent` (Linux) is Running. If not, restart: `Restart-Service` / sudo systemctl restart.
  2. Check TCP/443 connectivity to `globalconnectivity.azure.com` – this is the primary GSA tunnel endpoint.
  3. Run `Resolve-DnsName` / `nslookup` for the client CDN URL; ensure no internal DNS poisoning.

2. Analyze and Force Traffic Forwarding Profile Refresh

GSA profiles (app‑specific, tunnel‑all) are cached locally. Stale profiles cause misrouted traffic.

Windows Registry location:

`HKLM\SOFTWARE\Microsoft\GlobalSecureAccess\Profiles` – check `LastUpdateTime` and `ProfileVersion`.

Force refresh (Windows):

 Restart the GSA service to force profile re‑download
Restart-Service GlobalSecureAccess
 Clear local profile cache (backup first)
Stop-Service GlobalSecureAccess
Remove-Item -Recurse -Force "$env:ProgramData\GlobalSecureAccess\Profiles\"
Start-Service GlobalSecureAccess

Linux (clear and restart):

sudo systemctl stop global-connect-agent
sudo rm -rf /var/lib/global-connect-agent/cache/
sudo systemctl start global-connect-agent

Step‑by‑step guide:

1. Stop the GSA service.

  1. Delete the profile cache directory (Windows ProgramData; Linux /var/lib/.../cache).
  2. Start the service – it will fetch the latest forwarding policies from Entra.

4. Verify profile update by checking registry/file timestamps.

  1. Validate Primary Refresh Token (PRT) and Device State

A missing or invalid PRT breaks user‑based Conditional Access and device compliance.

Windows (Command Line as user):

dsregcmd /status

Look for:

– `AzureAdJoined: YES`
– `EnterpriseJoined: NO`
– `PrimaryRefreshToken: Not Expired`
– `Device Certificate Validity: [certificate is valid]`

If PRT expired or missing:

 Force re‑registration
dsregcmd /leave  Remove from Azure AD
dsregcmd /join  Rejoin
 Or trigger schedule task: Microsoft > Windows > Workplace Join > Automatic-Device-Join

Linux (with `connect-agent` installed):

connect-agent diagnostics prt-status
 If invalid, re-authenticate with:
connect-agent auth login --tenant <tenant-id>

Step‑by‑step guide:

  1. Run `dsregcmd /status` (Windows) or `connect-agent diagnostics` (Linux).
  2. If PRT is missing/expired, perform a device re‑join (/leave + /join).
  3. After rejoining, restart GSA service and re‑verify PRT state.

4. Proxy Configuration & Bypass Lists

GSA works even with corporate forward proxies, but misconfigured proxy exceptions (PAC/WPAD) can bypass the tunnel.

Windows – check system proxy:

netsh winhttp show proxy
 Also check per‑user proxy (registry):
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select ProxyEnable, ProxyServer

Set GSA to ignore proxy for its own endpoints (PAC example snippet):

if (shExpMatch(host, ".globalconnectivity.azure.com") ||
shExpMatch(host, ".gsaclient.azureedge.net"))
return "DIRECT";

Windows – configure WinHTTP proxy for LOCAL SYSTEM (GSA service context):

 Run as SYSTEM using PsExec or scheduled task
netsh winhttp set proxy proxy-server="http://proxy.corp:8080" bypass-list=".globalconnectivity.azure.com;.azureedge.net"

Linux – system proxy enviroment for GSA daemon:

Edit `/etc/systemd/system/global-connect-agent.service.d/proxy.conf`:

[bash]
Environment="HTTP_PROXY=http://proxy.corp:8080"
Environment="HTTPS_PROXY=http://proxy.corp:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.globalconnectivity.azure.com,.azureedge.net"

Then sudo systemctl daemon-reload && sudo systemctl restart global-connect-agent.

Step‑by‑step guide:

1. Identify corporate proxy (PAC, WPAD, or manual).

  1. Ensure GSA’s critical domains bypass proxy (DIRECT or NO_PROXY).
  2. Apply the bypass to service account context (Windows: `netsh winhttp` for SYSTEM; Linux systemd drop‑in).

4. Restart GSA service and test connectivity.

5. Leverage Advanced Diagnostics and Traffic Logs

Microsoft Entra Admin Center provides rich logs to correlate client errors with policy failures.

Accessing logs (Azure Portal):

  1. Go to Entra ID → Global Secure Access → Traffic Logs (filter by user, app, or destination IP).
  2. Open Sign‑in logs → add filter `Client app: Global Secure Access` to see authentication attempts.
  3. Use Advanced Diagnostics (under Monitor) → run query: 
    GlobalSecureAccessTraffic
| where TimeGenerated > ago(4h)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, DestinationUrl, ResultType, FailureReason

Local client logs (Windows):

 GSA logs are in Event Viewer: Applications and Services Logs > Microsoft > GlobalSecureAccess
 Export last 100 errors:
Get-WinEvent -LogName "Microsoft-GlobalSecureAccess/Operational" -MaxEvents 100 | Where-Object {$_.LevelDisplayName -eq "Error"} | Format-List

Linux log location: `/var/log/global-connect-agent/agent.log`

Step‑by‑step guide:

1. Reproduce the issue while capturing timestamps.

  1. Pull local client logs for errors (e.g., DNS failure, proxy timeout, PRT missing).
  2. Cross‑reference with Entra traffic logs – match `RequestId` or timestamp.
  3. Use failure reason strings to pinpoint policy (e.g., Conditional Access requires compliant device but device not registered).

6. Conditional Access Policy Overrides and Tunnel Exclusions

Sometimes GSA forwards traffic that should be excluded (e.g., Intune enrollment, Office 365 optimization). Review the GSA forwarding profile.

Get applied policies via Graph API (requires `Policy.Read.All`):

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgNetworkAccessFilteringPolicy -All

Check locally enforced exclusions (Windows) – registry:

`HKLM\SOFTWARE\Microsoft\GlobalSecureAccess\Exclusions` – lists IPs/FQDNs that bypass tunnel.

Modify exclusion list (example add `.myinternal.local`):

$exclusions = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\GlobalSecureAccess\Exclusions"
$newList = $exclusions.Domains + ".myinternal.local"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\GlobalSecureAccess\Exclusions" -Name "Domains" -Value $newList

Step‑by‑step guide:

  1. Verify if the failing destination is deliberately excluded (check Entra policy and local registry).
  2. If mis‑excluded, update the forwarding profile via Entra Admin Center (not locally – local changes are overwritten).
  3. Force profile refresh (Section 2) to pull the corrected policy.

What Undercode Say:

  • Trust but verify every layer – GSA depends on DNS, proxy, PRT, and local cache; a single stale component kills the tunnel.
  • Automate health checks – Use dsregcmd, Test-NetConnection, and log aggregation to catch failures before users report them.

Analysis:

Microsoft Entra GSA is powerful but opaque when broken. Most outages stem from expired device certificates (PRT), forward proxy SSL inspection that breaks tunnel negotiation, or outdated traffic profiles after policy changes. The commands above cut through the noise – forcing profile refresh, re‑joining the device to Entra ID, and bypassing corporate proxies for GSA endpoints resolves 80% of incidents. However, Conditional Access policies that require compliant devices remain a top hang‑up: admins must ensure Intune compliance scripts run before GSA initiates. Going forward, Microsoft will likely add native diagnostic tools inside the Entra admin center, but until then, mastery of local logs and Graph API queries separates reactive firefighting from proactive resilience.

Prediction:

By Q4 2026, Microsoft will embed an AI‑driven “GSA Troubleshooter” within the Entra portal that automatically parses client logs, PRT state, and proxy traces – drastically reducing time‑to‑resolution. However, this automation will rely on deeper telemetry collection, sparking privacy‑versus‑security debates in regulated industries. Edge cases like split‑tunnel exclusions and non‑Windows clients (Linux, macOS) will remain manual debugging domains for the foreseeable future.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Christopherbrumm Bookmark – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: