JUMP TO SECTIONChoose a lesson section
Identity-aware network access starts with the right traffic path.
Global Secure Access (GSA) is Microsoft's umbrella for the Microsoft Entra Internet Access secure web gateway and Microsoft Entra Private Access Zero Trust Network Access capabilities. The Microsoft traffic profile protects supported Microsoft services. Each forwarding profile acquires different traffic; acquisition is not the same thing as authentication or authorization.
Microsoft. Private. Internet. Three destinations, three roles.
Before touching a policy, classify the destination: Microsoft 365 service, corporate private resource, or public web/SaaS. The traffic forwarding profile decides which requests are captured and tunneled. Security and Conditional Access policies determine what happens to those requests once acquired, within their supported scope.
Microsoft traffic
Acquire supported Microsoft 365 and Entra services, including Microsoft 365 traffic forwarding with tenant protections, source-IP restoration and supported Compliant Network use.
Microsoft profile traffic is not rerouted through the general Internet Access profile. Compliant Network CA enforcement depends on a supported client context; a branch tunnel alone isn't proof.Private Access
Give specific users access to defined private hostnames/IP ranges, protocols and ports without opening an entire network through a traditional VPN.
Remote networks do not currently acquire Private Access flows. Use Quick Access or application segments and working private-network connectors.Internet Access
Apply identity-aware Secure Web Gateway controls to acquired general internet and third-party SaaS traffic, including supported web-content rules and security policies.
Private Access takes routing priority for matching private destinations. A web filtering rule is effective only when traffic is actually acquired and the applicable policy evaluates.Microsoft service traffic is reserved for the Microsoft traffic profile. Matching Private Access destinations take precedence over the general Internet Access profile. A private application isn't automatically subject to Internet Access web filtering. Always inspect the channel actually selected.
Installed ≠ connected ≠ forwarding.
A device can have the Global Secure Access client installed without being signed in, assigned the correct profile or acquiring an application's traffic. For Windows, the client exposes status and channel health in its system-tray interface; Advanced diagnostics reveals the tenant, device, profile, rules and per-connection actions.
License, scope and prerequisites
Confirm the tenant's available Microsoft, Private Access and Internet Access entitlements, admin roles, destination dependencies and client-platform requirements. Choose a small pilot group.
Enable the intended forwarding profile
In Entra admin center → Global Secure Access → Connect → Traffic forwarding, enable the relevant profile and assign it to your pilot identities. Configure required Microsoft/private/internet rules deliberately.
Prepare the endpoint
Install the current supported Global Secure Access client; validate tenant/device join, user sign-in and channel health. For Windows, check the system tray's Connections and Troubleshooting views.
Verify actual acquisition
Open Advanced diagnostics and inspect profile ID/update time, destination rules, tunnel/bypass/block action, channel and connection status. A green icon alone isn't enough.
Pilot security controls safely
Apply scoped application assignments, private-app Conditional Access or supported Microsoft/network controls. Preserve emergency access; test an approved and denied flow before expanding.
Watch logs and plan rollback
Correlate client traffic and network traffic logs with policy and connector evidence, collect change approval, confirm expected impact and maintain a rollback plan.
Look for these fields in a real investigation
Grant the finance app, not the whole subnet.
Northstar needs to publish an internal finance portal at finance.northstar.example on TCP 443. A traditional full-tunnel VPN can expose a much broader internal surface. Private Access can scope the user to the specific app, defined as an application segment. Quick Access is useful for initial, broader private destinations; a per-app Private Access enterprise application gives finer segmentation.
Define the resource
Determine the internal app's actual destination FQDN/IP, protocol and port. E.g. finance.northstar.example on TCP 443; determine whether per-app segmentation or broader Quick Access fits the business.
Create connector capacity
Deploy supported private network connectors close enough to the destination to resolve its DNS and reach the service. Assign a connector group and check health and availability.
Create the Private Access enterprise app
Quick Access creates a private-app enterprise application for initial broader resource sets. Prefer a specific per-app application for granular access; configure application segments.
Assign the intended users
Assign user/groups to the private application and enable the Private Access traffic profile for the supported pilot endpoints. A connector existing does not automatically authorize users.
Apply Conditional Access to the app
Target the Quick Access or Private Access enterprise application for applicable device, risk and authentication requirements. Do not assume a universal policy directly on raw private network traffic.
Prove end-to-end access
Verify client rule matches and tunnel action, then connector DNS/TCP reachability, correct user assignment and app-level policy. Test unauthorized destinations and ports remain denied.
Current Microsoft documentation requires the Global Secure Access client to acquire Private Access traffic. Remote-network connectivity supports the Microsoft and Internet profiles, not the Private Access profile. Likewise, apply Conditional Access for a private application to its associated enterprise application—not indiscriminately to raw traffic.
Web security and Microsoft 365 routing aren't the same pipeline.
Public web / third-party SaaS
The Internet Access traffic forwarding profile acquires eligible public destinations through the client or a supported remote network. Microsoft SSE can apply internet security profiles, web content filtering and other supported threat protections. Check both acquisition and the policy assigned to the flow.
Use a pilot group and confirm the service and feature licensing, web categories, destinations and actual network logs.Teams / SharePoint / Exchange
Enable and scope the Microsoft traffic profile to supported users/groups, then verify client or branch acquisition. It supports scenarios such as compliant-network checks, source-IP restoration and tenant restrictions under documented prerequisites.
Don't infer a Compliant Network Conditional Access outcome from a branch route alone: Microsoft documents client-specific enforcement limitations.Branch offices: supported remote-network connectivity can acquire Microsoft or Internet Access traffic without installing the client on every endpoint for those routes, but identity-aware Conditional Access enforcement and feature behavior depend on the acquisition path. That does not extend the same capability to Private Access.
Trace a flow before you troubleshoot it.
Switch between Microsoft 365, private applications, public internet, and branch traffic. Each Northstar example shows the intended forwarding chain, the evidence needed to prove it, a subtle deployment trap and a decision checkpoint.
Where does this connection actually go?
A private finance portal should not expose the whole network.
An approved employee needs finance.northstar.example on TCP 443. Northstar defines a per-app Private Access application and connector group.
- 01Endpoint
The supported Global Secure Access client acquires the private application segment
- 02Private Access profile
App segment matches finance.northstar.example, TCP 443; user/group is assigned the private app
- 03Microsoft SSE edge
Private Access channel checks scoped access and the target enterprise application's Conditional Access
- 04Private network connector
Healthy connector resolves the private hostname and can reach the internal server on TCP 443
- 05Internal application
The authorized user can open the finance portal, but unapproved destinations remain inaccessible
Inspect client Traffic action, destination/FQDN, matched rule, DNS and connector-group health. Then verify app assignment and Conditional Access at the enterprise application.
Private Access currently requires the endpoint client: supported branch remote-network forwarding does not acquire private destinations.
The client tunnels the private flow, but the internal portal times out. Which layer deserves attention?
Find the failing layer. Don't just disable the control.
Start with client channel status, then acquisition, policy, connector and resource reachability. Client Advanced diagnostics → Traffic shows action, destination, port, channel and rule. Compare that evidence with relevant Entra/Global Secure Access network logs and application events.
Global Secure Access client says Connected, but private app traffic bypasses.
First evidence: Inspect Traffic and Forwarding profile tabs. Check app segment FQDN/IP, protocol, port, DNS resolution and effective user/profile assignment.
Avoid: Don't interpret connection health as proof that every desired packet is acquired.Client tunnels finance.northstar.example:443, but the app times out.
First evidence: Confirm the correct private connector group is healthy and can resolve/reach that internal FQDN on TCP 443. Inspect the target service and network path.
Avoid: Don't broaden the user to an entire private subnet or switch to Global Administrator as a connectivity fix.Microsoft 365 sign-ins are blocked after Compliant Network was required.
First evidence: Inspect CA sign-in policy evaluation, app/user scope, supported acquisition path, client channel and forwarding assignment. Use controlled remediation and a pilot.
Avoid: Don't assume a branch remote-network tunnel without the client automatically satisfies Microsoft-traffic CA enforcement.A branch can browse public sites, but an internal private app remains inaccessible.
First evidence: Confirm the branch uses Microsoft/Internet acquisition only. For private app access, verify an end-user GSA client plus Private Access segments/connectors.
Avoid: Don't claim remote-network Private Access is supported when Microsoft's current known limitations say otherwise.Private host works by IP, but the FQDN isn't tunneled.
First evidence: Check device DNS settings, possible DNS-over-HTTPS behavior, forwarding FQDN rule acquisition, resolved IP and whether the segment matches.
Avoid: Don't bypass all DNS protections or delete unrelated policies without tracing the actual resolution.Client support, network/DNS limitations, licensing, Conditional Access integrations and profile features change over time. Verify Microsoft's current known limitations and rollout prerequisites. These simulated routing paths are conceptual, not a packet capture or a live tenant configuration.
Use Microsoft's current docs for actual implementation.
JoeLearns teaches the troubleshooting relationships and least-privilege design. Microsoft Learn supplies the supported setup steps, product caveats and roles for a production tenant.
The tunnel is up. Can you prove the app works?
Practice 016 includes original flashcards, explained questions and two multi-step Northstar routing investigations.