By the end of this you have two registered connectors in a group that is not Default, a Quick Access application carrying the whole private estate, private DNS answering for your forest suffix, and one application segment promoted out of Quick Access into its own enterprise application with its own assignment and its own Conditional Access. Proven with a test that shows which rule won, rather than one that shows the connection worked.
Before step 1 you need: a Microsoft Entra ID P1 or P2 licence plus the Microsoft Entra Private Access licence for every user in scope; the Global Secure Access Administrator and Application Administrator roles, both of them, because connector groups and application publishing are separate permission surfaces; two Windows Server hosts inside the network you intend to publish; and the Global Secure Access client already deployed to at least one pilot device. If the client is not deployed yet, do that first. The packaging pattern is in [GSA 3.1] and it does not change here.
The reasoning behind the sequence, and the argument for why Quick Access comes first and stays permanently, is in [GSA 4]. This article does not repeat it. Read that one if you want to know why you are building it in this order.
The estate this is built against
Everything below is written against a real shape rather than a generic one, because the awkward parts of Private Access only appear when the estate has a history. Catsnackjack runs a single Active Directory forest with the flat DNS name catsnackjack.com. That same name is registered publicly and already carries external records, including pki.catsnackjack.com from the certificate services build. The estate is therefore split-brain, which is the common case in the mid-market and the case Microsoft does not document.
| Object | Value | Role in this build |
|---|---|---|
| Forest and domain | catsnackjack.com | The DNS suffix published to private DNS |
| Server subnet | 10.20.10.0/24 | Inside the broad Quick Access segment |
| Whole Brisbane range | 10.20.0.0/16 | The broad Quick Access segment |
| Connector host 1 | csj-gsaconn01.catsnackjack.com | Windows Server 2022, 4 vCPU, 8 GiB |
| Connector host 2 | csj-gsaconn02.catsnackjack.com | Second connector, different hypervisor host |
| Pilot application | intranet.catsnackjack.com, 10.20.10.40 | 443/TCP, the segment promoted in step 10 |
| Domain controllers | dc01, dc02.catsnackjack.com | Published in [GSA 4.2], not here |
Naming convention
Private Access objects accumulate faster than anything else in Entra, because every segmentation decision produces another enterprise application. Decide the naming before you create the second object, not after the twentieth. The convention used throughout this series is three fields separated by hyphens: organisation prefix, object class, then scope.
| Object class | Pattern | Worked example |
|---|---|---|
| Connector group | CSJ-CG-site–role | CSJ-CG-BNE-PROD |
| Maintenance group | CSJ-CG-site-MAINT | CSJ-CG-BNE-MAINT |
| Enterprise application | CSJ-PA-workload | CSJ-PA-Intranet-Web |
| Assignment group | SG-GSA-PA-workload | SG-GSA-PA-Intranet-Web |
Quick Access is the single exception and it does not take the convention. Microsoft’s own instruction is to call it Quick Access, and several documented behaviours and support articles refer to it by that display name. Rename it and you will spend an afternoon explaining yourself to somebody in a support case.
Step 1. Build the connector hosts
The connector is the same private network connector that Application Proxy has used for years, with the publishing object extended past HTTP. That lineage explains most of its prerequisites and all of its odd corners.
| Setting | Value | Why |
|---|---|---|
| Operating system | Windows Server 2016 or later | Documented floor. Build on 2022 or 2025; 2016 is the floor, not the target |
| vCPU | 4 or more | CPU is the constraint, because the connector terminates TLS both ways |
| Memory | 8 GiB or more | Microsoft’s stated recommendation. Memory is rarely the limit |
| Disk | Whatever your build standard is | Microsoft publishes no disk minimum. Do not invent one |
| .NET Framework | 4.7.2 or later | Two of three Microsoft statements say 4.7.2 and one says 4.7.1. Build to the higher. Windows Server 2016 does not ship it |
| TLS 1.2 | Enabled for client and server, plus SystemDefaultTlsVersions and SchUseStrongCrypto on .NET 4.0.30319 | Registration fails without it, and the failure message does not say so |
| Outbound 443/TCP | Open to *.msappproxy.net and *.servicebus.windows.net | The data path. Both tunnels run over this |
| Outbound 80/TCP | Open to the DigiCert and Microsoft CRL and OCSP endpoints | Certificate revocation checking during registration and renewal |
| Inbound ports | None | Connectors dial out only. If somebody asks you to open an inbound rule, they have misread the architecture |
| TLS inspection | Excluded for connector traffic | The connector authenticates with a client certificate. Inspection strips it and registration fails |
| Placement | Same site as the resources | Every private flow makes two hops through this host. Put it next to what it publishes |
Two operational facts about the hosts themselves. Do not install the connector alongside Microsoft Entra Password Protection Proxy, because the two ship incompatible versions of the Connect Agent Updater and will fight. Do not run the connector on a machine that hosts virtual machines. Both are documented and both are found the hard way.
If your estate forces outbound traffic through a forward proxy, the connector supports it. Configuration is by editing the service configuration file rather than any portal control, and there is a hard constraint worth knowing before you plan: proxy authentication is not supported, so the connector needs anonymous egress to the destination list above. Note also that Microsoft’s own connector concept page still warns that forward proxies can break the two-way certificate authentication, a sentence that was not reconciled when outbound proxy support went generally available in 2024 and remains live today. Both statements are current. Plan for the supported path and keep the warning in mind if registration behaves strangely.
Step 2. Register the connectors
Download the connector from Global Secure Access then Connect then Connectors. Take the build from that page rather than any file you already have on a share, because the versions matter more than they look.
The current build at the time of writing is 1.5.4892.0, released 8 June 2026, and it is explicitly download-only. The last build Microsoft flagged as eligible for automatic upgrade was 1.5.4522.0 on 10 October 2025. Read that pairing carefully, because it means connector patching is a standing manual duty in your operations calendar and not a thing the service does for you. The minimum version that supports Private Access at all is 1.5.3417.0, which is the number to check if you inherit an estate with connectors already in place.
Registration needs Global Administrator for the first connector in the tenant and Application Administrator for every one after it. Two Windows services must be running when you are done, named Microsoft Entra private network connector and Microsoft Entra private network connector updater. If the updater service is stopped, you have opted out of the automatic path entirely, including the releases that do qualify.
Register the second connector on a different hypervisor host and, if you can, a different outbound path. A connector pair that shares a host and a firewall is a pair on paper.
Step 3. Create the connector group, and the maintenance group with it
Every new connector lands in Default. That is the reason not to publish anything to Default: a connector you registered five minutes ago, possibly in the wrong site, possibly with no route to the resource, starts serving production traffic the moment it comes up. Default should hold new and idle connectors and nothing should be assigned to it.
Create CSJ-CG-BNE-PROD and move both connectors into it. Two is the documented floor for high availability and the load balancing page prefers three, on the reasoning that two gives you no headroom while one is being patched. If you are sizing for a production estate rather than a pilot, build three.
Now create the second group, CSJ-CG-BNE-MAINT, and assign it to exactly one thing: a throwaway Private Access application used as a connectivity probe and nothing else. This is Microsoft’s documented drain pattern and it is the single most useful thing in this step. Moving a connector into the maintenance group stops new connections landing on it while existing sessions finish. Patch it, reboot it, confirm both services are healthy, test through the probe application, then move it back.
One caution about that pattern, from Microsoft’s own failure-handling guidance a few pages away: existing connections do not drain immediately when you change group membership, and the prescribed way to force a drain during an unplanned failure is to restart the server. No drain interval is published for the planned case. In practice you are waiting on your longest-lived session, which in an estate carrying RDP means the length of somebody’s working day. Plan the maintenance window against that, not against a number Microsoft did not give you.
Step 4. Enable the Private Access traffic forwarding profile
Under Global Secure Access then Connect then Traffic forwarding, enable the Private access profile and scope it to a group. Do not scope it to all users on the day you turn it on. The profile assignment is a separate surface from application assignment and it has the same constraint that catches people everywhere else in this product: nested groups are not evaluated. Members must be direct.
Budget up to an hour for a profile change to reach a client, which is a different number from the fifteen minutes an application configuration change takes and the five to ten minutes a new application definition takes. Three propagation timers, three different documented values, and conflating them is how people conclude a build is broken when it is merely young.
Step 5. Quick Access, and the port expression that leaves DNS alone
Create Quick Access under Global Secure Access then Applications then Quick Access. Name it Quick Access. Point it at CSJ-CG-BNE-PROD. Then add the segment that replaces the VPN.
| Setting | Value | Why |
|---|---|---|
| Destination type | IP address range (CIDR) | The whole site, because this is the VPN replacement phase |
| Destination | 10.20.0.0/16 | Everything the VPN used to reach |
| Ports | 0-52,54-65535 | Every port except 53 |
| Protocol | TCP and UDP | Both, or half your estate silently bypasses |
That port expression is Microsoft’s own, from the VPN replacement tutorial, and the carve-out is deliberate. Port 53 is excluded because private DNS does not travel as ordinary segment traffic. It works by installing Name Resolution Policy Table rules on the client that redirect matching queries to a synthetic resolver, and the edge answers them. Leave 53 inside the segment and you tunnel every DNS query by IP match instead, including public resolution, which is both slower and not what the design intends.
Two limits to know before you build the segment list. A Quick Access application holds up to 500 application segments. And tunnelling to a private destination by IP address only works for ranges outside the end-user device’s own local subnet, which means a home network numbered inside a range you have published will not tunnel to it. In a 10.20.0.0/16 estate that is unlikely. In a 192.168.1.0/24 estate it is close to guaranteed.
Quick Access is not a temporary scaffold you take down when segmentation is finished. It hosts private DNS and it feeds application discovery. Remove it and you remove name resolution and your own inventory at the same time.
You will find a Microsoft page that tells you to disable Quick Access as the final step of segmentation. It is the architecture-hub deployment guide, last revised January 2025. The current product documentation, revised June 2026, says the opposite in a section headed with the question directly: Quick Access is not designed to be removed entirely and is expected to remain in place even in mature deployments. Follow the newer page. It also supplies the mechanism the older one ignores, which is that private DNS suffixes live on Quick Access and application discovery reads only Quick-Access-matched traffic.
Step 6. The pre-flight check that saves the DNS build
Before you configure a single DNS suffix, check whether Group Policy is already writing Name Resolution Policy Table rules in your estate. The Global Secure Access client configures local NRPT rules to make private DNS work, and Group Policy NRPT rules override local ones. Private DNS then silently does nothing.
Worse, and this is the version that catches estates with long memories: a Group Policy Object that once contained NRPT rules which were later deleted leaves an empty NRPT list in its registry.pol file, and an empty list overrides local rules exactly as a populated one does. The GPO looks clean in the editor. It is not.
$polFiles = Get-ChildItem -Path "\\catsnackjack.com\sysvol\catsnackjack.com\Policies" -Recurse -Filter "registry.pol"
foreach ($pol in $polFiles) {
$bytes = [System.IO.File]::ReadAllBytes($pol.FullName)
$text = [System.Text.Encoding]::Unicode.GetString($bytes)
if ($text -match "DnsPolicyConfig") {
Write-Output "NRPT keys present: $($pol.FullName)"
}
}Any hit is a GPO you must clean or scope away from Private Access devices before private DNS will work. On the pilot device itself, confirm the client-side state directly.
Get-DnsClientNrptPolicy | Format-Table Namespace, NameServers, DnsSecEnableTwo other client conditions belong in the same pre-flight. Secure DNS must be off, in every form, at the operating system and in each browser individually, because the client does not support DNS over HTTPS, DNS over TLS or DNSSEC. And DNS over TCP on port 53 is not supported either, which is why the browser built-in resolvers have to be disabled rather than merely pointed elsewhere.
Step 7. Private DNS, and what split-brain does to it
Private DNS is configured on Quick Access, on the Private DNS tab of its network access properties. Enable it and add the suffix. For this estate that is catsnackjack.com, the forest root, which Microsoft names as the minimum you should publish.
Now read the sentence that governs everything downstream. When a suffix is configured in Quick Access, all DNS queries for a name ending in that suffix are resolved by private DNS, including the names used to define enterprise applications. The match is unconditional and terminal. There is no exclusion list, no negative match, and no per-subdomain carve-out anywhere in the product.
In this estate that has a consequence Microsoft does not document, because Microsoft does not address split-brain at all. Publishing catsnackjack.com as a private suffix pulls pki.catsnackjack.com under the tunnel too, even though it is a public name with a public record that resolves perfectly well without help. Every certificate revocation check and every AIA fetch from a client with the profile enabled now depends on a connector being up. I want to be exact about the epistemic status here: the behaviour follows directly from the documented rule that all queries matching the suffix are resolved by private DNS, but Microsoft states neither the split-brain case nor its remedy. This is inference from a cited rule, not a cited claim.
The practical handling, in order of preference. Publish the internal name as a segment so the tunnel resolves it correctly and reaches the internal instance, which is fine when the internal and external instances are the same service. Where they are not, and certificate distribution points are the usual example, move the external service to a name outside the forest suffix. This is the argument for a dedicated public zone that has nothing to do with the AD name, and it is an argument you will make more persuasively before you deploy Private Access than after.
Two more properties of private DNS worth carrying. Single-label names are resolved by appending a synthetic suffix, and Microsoft flags directly that the synthetic suffix can break Kerberos because the service principal name the client constructs will not match the one registered in Active Directory. The instruction that follows is one line and it governs the next build sheet: publish and reference private resources by fully qualified name, never by short name, wherever Kerberos is involved. And reverse lookups are undocumented in both directions. No page says PTR queries tunnel and no page says they do not. Do not build anything that depends on it.
Step 8. Assignment, and the Conditional Access trap on Quick Access
Assign users to Quick Access through a group, direct members only. Then apply Conditional Access at the application level, because Conditional Access targeting the Private Access traffic profile is not supported. Per-application policy on Quick Access and on each Global Secure Access application is the documented design, not a workaround.
There is one policy shape to avoid on Quick Access specifically, and it is the kind of mistake that produces an incident rather than an error message. Because private DNS runs on Quick Access, Conditional Access applied to Quick Access evaluates DNS queries. A policy that requires multifactor authentication with a sign-in frequency on Quick Access will therefore prompt users at unpredictable moments driven by name resolution rather than by anything they did. Require multifactor authentication if you want to. Do not attach a sign-in frequency to it here.
The other control worth stating plainly, because it comes up in every design review: the compliant network check is not supported for Private Access applications. If you built the compliant network policy in [GSA 3.1], it governs Microsoft traffic and it does not govern these. Use device compliance or hybrid join as the grant control on private applications instead.
Step 9. Prove the foundation before you segment anything
On the pilot device, open Advanced Diagnostics from the client and run the Health check tab. It runs roughly two dozen tests and they are ordered by dependency, so resolve the first failure, refresh, and repeat rather than working the list. The failures that matter at this stage are the forwarding profile registry existing and matching its schema, the edge being reachable, tunnelling succeeding, and break-glass mode being off.
Then confirm name resolution goes where you think. Note which tool you use, because it decides the answer.
Resolve-DnsName intranet.catsnackjack.com
nslookup intranet.catsnackjack.com 6.6.255.254Resolve-DnsName honours the NRPT and therefore shows you what applications will see. Plain nslookup does not honour the NRPT and will answer from your ordinary resolver, which is why it is the single most common source of a false negative in this build. If you want nslookup to test the tunnel, you have to aim it at the synthetic resolver address explicitly, as above.
If a rule refuses to arrive, force the policy refresh rather than waiting on the hour.
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Global Secure Access Client" -Name "ForwardingProfileTimestamp"
Restart-Service -Name "GlobalSecureAccessPolicyRetrieverService"Step 10. Promote one segment, and rescope it
Leave Quick Access running for long enough to collect traffic, then open Global Secure Access then Applications then Application discovery. It reports the application segments in Quick Access that users reached through the client in the last thirty days, with destination FQDN, destination IP, transport protocol, port, user count, transaction count and byte counts.
Understand what that list is before you plan around it. Discovery reads Quick-Access-matched client traffic and nothing else. It is not a network scan and it is not connector telemetry. Anything Quick Access never covered was never seen, and anything you have already segmented into its own application disappears from the list, by design, because it no longer matches Quick Access. Discovery is a burn-down list against Quick Access, not an inventory of your estate. That distinction decides whether you can use it as evidence of completeness. You cannot.
Select the intranet rows and use Add to new application. Name it CSJ-PA-Intranet-Web, point it at CSJ-CG-BNE-PROD, and build the segments deliberately rather than accepting only what discovery prefilled.
| Setting | Value | Why |
|---|---|---|
| Segment 1 destination | intranet.catsnackjack.com (FQDN) | The name users and Kerberos both use |
| Segment 2 destination | 10.20.10.40 (IP address) | The address the FQDN resolves to. Without this the segment leaks |
| Ports | 443 | Only what the application serves |
| Protocol | TCP | UDP adds nothing here and widens the rule |
| Quick Access change | Carve 10.20.10.40 out of the broad range | So the enterprise application is the only match for that address |
The second segment is the part people skip and it is the part that matters. When you move an FQDN into an enterprise application, only traffic addressed to that name and resolved through private DNS follows the new application’s configuration. Traffic sent straight to the IP address, which is what any process holding a cached address does, keeps matching Quick Access if that address is still inside a Quick Access range. The effect is not a routing curiosity. It is a policy gap: the tighter assignment and the tighter Conditional Access you just built are silently not applied to that traffic, which falls back to the broad Quick Access grant instead. Add the resolved addresses to the application and remove them from Quick Access, in that order.
Then handle assignment, and handle it by checking rather than by assuming, because Microsoft’s documentation genuinely disagrees with itself here. The per-app how-to states flatly that access assignments are not transferred to a new enterprise application even where an overlapping segment existed in Quick Access. The application discovery page states that applications created through discovery inherit all assigned users and groups from Quick Access at creation. The segmentation tutorial describes an opt-in checkbox labelled Import users and groups from Quick Access application and says that leaving it unchecked creates the application with nobody assigned. All three pages are live.
The defensible position is to never rely on inheritance in either direction. Open the application’s users and groups list, read what is actually there, and set it to SG-GSA-PA-Intranet-Web deliberately. Then rescope: if the application did inherit everyone from Quick Access, you have just published a per-app segment with tenant-wide access, which is the opposite of what segmentation is for.
One more discovery behaviour that will otherwise waste an hour. A segment stays in the discovery table after you promote it, until a user signs in to the new application and reaches the resource. Seeing it still listed immediately afterwards is expected and is not evidence the promotion failed.
The end-to-end test: prove which rule won
A successful connection to intranet.catsnackjack.com proves almost nothing at this point, because Quick Access would have carried it perfectly well before you built anything. The claim that needs proving is narrower and it is the whole point of the step: the enterprise application, with its own assignment and its own policy, is what governed that connection. Three stages, all on the pilot device, all reading tools rather than inferring.
Stage one, the forwarding profile. Open Advanced Diagnostics and go to the Forwarding profile tab. Enable the Priority, Rule ID and Application ID columns. Under Private access rules, find the row for intranet.catsnackjack.com on 443/TCP. Two assertions: the Application ID is the object ID of CSJ-PA-Intranet-Web and not Quick Access, and its Priority value is numerically smaller than the Quick Access rule covering the same destination, because smaller wins. Write down the Rule ID.
Stage two, the policy tester. Still on the Forwarding profile tab, use Policy tester against the destination. It returns the active rule for that destination, which is the same question a human answers badly by squinting at a rule list. It should return the enterprise application’s rule.
Stage three, the observed flow. Move to the Traffic tab, select Start collecting, and reach the application. You want one row where Action is Tunnel, Channel is Private Access, and Rule ID equals the value you recorded in stage one. That last equality is the join. It is what ties an observed packet flow to a specific application’s rule, and without it you have a working connection and an assumption.
Note what is deliberately not in that sequence. There is no Priority column on the Traffic tab. Priority is a property of a forwarding-profile rule, not of a flow, and any test that tells you to read priority off observed traffic is describing a screen that does not exist.
Two optional additions if you want a fuller picture. The Hostname acquisition tab has an Acquired column that answers yes or no on whether an FQDN matched a forwarding profile rule at all, which is the cleanest single cell in the whole tool. And the Correlation vector ID from the Traffic tab appears in the portal traffic logs under the name Connection ID, which is how you find out which connector actually handled the flow.
Finally, prove the negative. Remove your test user from SG-GSA-PA-Intranet-Web, wait fifteen minutes, and try again. Access should fail, and it should fail even though the address still sits inside the broad Quick Access range the user is still assigned to. That failure is the evidence that segmentation is doing something. A test that only ever passes has told you nothing.
The same build in Graph
Everything above has a portal path and everything above is worth doing once by hand, because the object model only makes sense when you have watched it assemble. After that it should be code. Two warnings before you copy this. Every segment operation is beta only; there is no v1.0 equivalent. And Microsoft publishes no PowerShell cmdlet for application segments, so the calls below go through Invoke-MgGraphRequest against the REST path rather than pretending a cmdlet exists.
Connect-MgGraph -Scopes "Application.ReadWrite.All", "NetworkAccess.ReadWrite.All", "Directory.ReadWrite.All"
# 1. Instantiate the Custom application template. The template ID is fixed.
$instance = Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/applicationTemplates/8adf8e6e-67b2-4cf2-a259-e3dc5476c621/instantiate" -Body @{ displayName = "CSJ-PA-Intranet-Web" }
$appObjectId = $instance.application.id
$spObjectId = $instance.servicePrincipal.id
# 2. Mark it a Private Access enterprise application.
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/applications/$appObjectId" -Body @{
onPremisesPublishing = @{
applicationType = "nonwebapp"
isAccessibleViaZTNAClient = $true
}
}
# 3. Bind it to the connector group. Note this is PUT, not POST.
$groupId = "REPLACE-WITH-CONNECTOR-GROUP-ID"
Invoke-MgGraphRequest -Method PUT -Uri "https://graph.microsoft.com/beta/applications/$appObjectId/connectorGroup/`$ref" -Body @{
"@odata.id" = "https://graph.microsoft.com/beta/onPremisesPublishingProfiles/applicationProxy/connectorGroups/$groupId"
}
# 4. Add the two segments. Ports are STRING RANGES, not integers.
$segmentPath = "https://graph.microsoft.com/beta/applications/$appObjectId/onPremisesPublishing/segmentsConfiguration/microsoft.graph.ipSegmentConfiguration/applicationSegments"
Invoke-MgGraphRequest -Method POST -Uri $segmentPath -Body @{
destinationHost = "intranet.catsnackjack.com"
destinationType = "fqdn"
ports = @("443-443")
protocol = "tcp"
}
Invoke-MgGraphRequest -Method POST -Uri $segmentPath -Body @{
destinationHost = "10.20.10.40"
destinationType = "ipAddress"
ports = @("443-443")
protocol = "tcp"
}Four things about that segment body are genuinely strange and all four are real. The ports property is a collection of strings expressing ranges, so a single port has to be written as a degenerate range, 443-443, and not as 443. There is also a legacy port integer property which appears in Microsoft’s own worked example and which the resource reference marks deprecated with an instruction not to use it; omit it. The protocol property accepts the comma-joined string tcp,udp for both protocols even though that value does not appear in the published enumeration. And destinationType has five values in Graph against four in the portal, the extra one being dnsSuffix, which is how private DNS suffixes are created through the API by posting to this same endpoint with no ports at all.
One more contradiction to be aware of rather than blocked by. The onPremisesPublishing resource reference documents applicationType as system-defined and read only, and Microsoft’s own tutorial writes it in a PATCH. The PATCH is the documented working path. Use it and note the disagreement.
When it does not work
The diagnostic ladder for this build has a fixed order and following it out of order wastes hours. Wait first, because the timers are real: five to ten minutes for a new application definition, fifteen for a configuration or assignment change, up to an hour for a profile. Then health check the client. Then look at the Forwarding profile tab and ask whether the rule exists at all, because if it does not, the problem is service side and nothing you do on the endpoint will help. Then Hostname acquisition, where an Acquired value of no means the name never matched a rule. Then the Traffic tab with the Action filter removed, because the most common real cause is not a missing rule but an incomplete one: a segment that publishes TCP where the application also speaks UDP, and the UDP half quietly bypasses to the local network while the TCP half works.
Three environmental conditions produce exactly the symptom of a correct segment that never tunnels, and none of them will show up as an error. IPv6 is not tunnelled at all, so a name that also resolves to an AAAA record may never take the IPv4 path. IP-based segments inside the device’s own subnet never tunnel. And traffic injected into the network stack by a driver rather than sent through a socket is not acquired, which means port scanners are not a valid test tool for this product no matter how convenient they are.
What you have at the end of this is a foundation, not a finished design: a broad tunnel that has replaced the VPN, a name resolution path you have proven rather than assumed, and one segment carved out of the broad tunnel with its own identity boundary. The next build sheet takes the two workloads that actually justify the effort, on-premises file shares and remote desktop, and publishes them with Kerberos single sign-on intact.
Global Secure Access
‹ Previous: [GSA 4] Private Access: Retiring the VPN Without Lying About It
Next: [GSA 4.2] Build Sheet: On-Prem File Shares and RDP Through Private Access ›
