agentleFS
vinayaklatthevinayaklatthe/microsoft-security-skills/skills/entra-global-secure-access/SKILL.md

entra-global-secure-access

Skill179 starsChanged 5 months agoMITView on GitHub

Guidance for Microsoft Entra Global Secure Access (GSA) — Microsoft's Security Service Edge (SSE) combining Entra Internet Access (SWG/Secure Web Gateway) and Entra Private Access (ZTNA replacement for VPN). Covers client deployment (Windows, macOS, iOS, Android), traffic forwarding profiles (Microsoft, Internet, Private), Conditional Access for network traffic, source IP restoration, app discovery, Quick Access and per-app access for Private Access, connector deployment, branch site connectivity (IPSec), TLS inspection, and Universal CA integration. WHEN: Entra Global Secure Access, GSA, Microsoft SSE, Entra Internet Access, Entra Private Access, ZTNA Microsoft, replace VPN with ZTNA, secure web gateway Entra, Conditional Access on network, source IP restoration, Quick Access app, Private Access connector, branch IPSec to Microsoft, GSA client rollout. DO NOT USE for general Conditional Access policy design (use conditional-access-mfa), Azure VPN/ExpressRoute design, or third-party SSE (Zscaler/Netskope) configuration.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Private Access connectors need outbound 443 only: No inbound NAT/firewall holes — that's the whole point.

    line 86

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Microsoft Entra Global Secure Access

Global Secure Access (GSA) is Microsoft's Security Service Edge (SSE) platform delivered through the Entra control plane. It has two products that share one client, one policy surface, and one identity model:

  • Entra Internet Access — secure web gateway (SWG) for internet and Microsoft 365 traffic with Conditional Access applied to network flows.
  • Entra Private Access — ZTNA replacement for traditional VPN, fronting on-prem and IaaS apps through Entra-authenticated connectors (evolution of Entra App Proxy).

When to use

Replacing VPN with ZTNA, applying Conditional Access to outbound internet traffic, restoring source IP for M365 sign-ins from the GSA client, or providing remote-worker access to TCP/UDP apps that aren't HTTPS.

Do not use this skill for generic CA policy authoring (conditional-access-mfa), hybrid network design (azure-network-security-design), or competing SSE products.

Traffic forwarding profiles

ProfileTraffic capturedUse case
Microsoft profileEntra ID + M365 trafficSource IP restoration, CA on network for M365
Internet Access profileAll internet egressSWG, web filtering, CA on internet traffic
Private Access profileDefined private apps (on-prem, IaaS)ZTNA, VPN replacement

Each profile is assigned to users/groups; user can be in all three concurrently.

Approach

  1. Start with the Microsoft profile, even if you're not buying full SSE yet. It's included with Entra ID P1/P2 (in preview/GA per region). Benefits:
    • Source IP restoration → CA policies that "require trusted network" actually work for remote users on the GSA client.
    • Compliant network check in CA: only requests through GSA satisfy the condition.
  2. Pilot the GSA client on a small group (50–200 users). Validate:
    • Latency to top apps (M365, internal HR, SAP) ≤ baseline + 30 ms.
    • Captive portals still work (hotel/airport Wi-Fi).
    • Conflict check with existing VPN clients, third-party endpoint protection, and personal firewalls.
  3. Roll out Private Access in parallel with VPN, not as a flag-day cutover.
    • Quick Access = the "easy migration" app: a wildcard FQDN/IP segment per site, pre-authenticated by Entra. Use for legacy back-end services.
    • Per-app access = define one Entra app per service with explicit FQDN/port/protocol and CA assignment. Use for high-value apps (SAP, file shares, RDP jump hosts).
    • Deploy Private Access connectors in HA pairs per region/site (same model as App Proxy connectors).
  4. Internet Access — start in monitor-only for 14 days. Build the baseline of destinations before turning on web-category blocks. Apply TLS inspection only to selected categories (don't break banking/healthcare per local law).
  5. Conditional Access on network — author CA policies that include All Compliant Network locations. Combine with device compliance + user risk for a real "Zero Trust" posture, not just "VPN with new branding."
  6. Branch / site connectivity — for office locations, terminate IPSec tunnels from the site router/SD-WAN to GSA so guest devices and IoT still get filtered without the client.
  7. Migration off VPN — once 80%+ of users are stable on GSA Private Access for the target app set, decommission VPN concentrators. Keep one for break-glass and third-party-managed devices.

Guardrails

  • GSA client and a third-party SSE/VPN client coexist poorly. Network stack hooks collide. Pick one tunnel per machine; pilot before mass rollout.
  • Source IP restoration only works for traffic through the Microsoft profile. Direct M365 access (split tunnel disabled) bypasses GSA → CA "trusted network" fails.
  • Don't deny-all on Internet Access on day one. Baseline first; finance teams visit obscure SEC URLs you've never seen.
  • TLS inspection requires CA distribution. Without the Microsoft CA installed in the trust store, every HTTPS site breaks. Plan rollout via Intune/MDM.
  • Private Access connectors need outbound 443 only. No inbound NAT/firewall holes — that's the whole point.
  • Quick Access is a stepping stone, not a destination. Wide wildcards mean excessive trust. Migrate to per-app access.
  • Licensing is segmented. Microsoft profile features are bundled with Entra P1/P2; Internet Access and Private Access are separate add-ons. Confirm SKUs before scope.

Common anti-patterns

  • "Flag-day VPN cutover" — a connector misconfig affects 30,000 users. Parallel run.
  • "Quick Access for everything, forever" — wildcard trust = ZTNA in name only.
  • "Allowed split-tunnel exceptions for M365 to fix latency" — now CA can't see the traffic; "trusted network" condition silently false.
  • "TLS inspection on banking/healthcare categories" — regulatory violation in some jurisdictions. Exclude.
  • "Deployed Internet Access in block mode on day one" — global outage of unexpected SaaS dependencies.
  • "GSA client + persistent always-on VPN coexisting" — routing conflict; client fights itself. Pick one tunnel.
  • "Connectors in a single AZ" — site outage = app outage. Always HA pair across AZ.

Example prompts

  • Roll out GSA Microsoft profile to 30,000 users for source IP restoration and CA trusted-network policies.
  • Replace Cisco AnyConnect VPN with Entra Private Access for 12 internal apps and 3 jump hosts.
  • Design Private Access connectors for 4 regions with HA and capacity sizing.
  • Pilot Internet Access in monitor mode for finance; identify blockable web categories vs allow-list.
  • Plan TLS inspection rollout with Microsoft CA distribution via Intune.
  • Build Conditional Access policy: require compliant device + compliant network for privileged users.
  • Branch-site IPSec to GSA from a Meraki edge — design and routing.

Microsoft Learn

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.