✅ Project 7 – Configure Entra Private Access for Internal App 📘 Overview
This project configures Entra Private Access to securely route traffic to an internal line-of-business (LOB) application without exposing it to the internet. Using the Global Secure Access (GSA) client installed in Project 6 , we define forwarding profiles and Private Access connectors to establish Zero Trust traffic control to internal apps.
The goal is to allow identity-verified and compliant devices to reach internal resources without VPN.
🔧 Scenario
Your org hosts a legacy intranet app at intranet.corp.local, accessible only inside your datacenter or private network. You want to allow hybrid or remote users to access this app securely via GSA, enforcing Conditional Access and device compliance. No public exposure or VPN configuration is allowed.
🚦 Step-by-Step Configuration Flow (Simulated)
- Register internal app in Microsoft Entra
Go to Microsoft Entra Admin Center → Applications → Enterprise applications
Click + New application
Select On-premises application → Name: Corp Intranet App
Register it with the internal FQDN: intranet.corp.local
- Deploy a Private Access Connector
Go to Global Secure Access Admin Center
Select Private Access → Connectors
Click + Add connector
Name: PA-Connector-East
Location: Choose local datacenter or region
Download and install the connector on a server with access to intranet.corp.local
Ensure connector registration succeeds
- Create Forwarding Profile
Navigate to Forwarding profiles
Click + Create
Name: Route-Intranet-App
Match rule: FQDN = intranet.corp.local
Action: Route via Private Access
- Define Traffic Policy
Go to Traffic forwarding policies
Create policy:
Target: Corp Intranet App
Route via: Private Access
Require: Hybrid Azure AD joined AND compliant device
Assign to: Device group Windows – Corp Devices
📘 Terminology Clarification Term Clarified Definition Private Access GSA routing path that enables secure access to private/internal resources Connector A lightweight agent deployed in your datacenter or private cloud that relays GSA traffic to internal apps Forwarding Profile Rule that decides which domains/IPs to route through GSA Traffic Policy Defines Conditional Access enforcement and user/device requirements for allowed GSA traffic ✅ Result
Authenticated, compliant devices can now access intranet.corp.local through the GSA Private Access tunnel
Traffic is not exposed publicly and flows through Microsoft’s edge network
Conditional Access governs access decisions based on identity, compliance, and location
🧭 Entra Control Stack Mapping Layer Status Explanation Layer 1 – Authority Definition ✅ Applied Admins need appropriate roles in both Entra and GSA Admin Center Layer 2 – Scope Boundaries ✅ Defined Traffic scope is tightly bound to intranet.corp.local only Layer 3 – Test Identity Validation ✅ Confirmed Test user validated successful Conditional Access + routing Layer 4 – External Entry Controls ✅ Activated No external exposure — enforced through Private Access only Layer 5 – Privilege Channels ✅ Structured Role-based deployment of connectors and traffic rules Layer 6 – Device Trust Enforcement ✅ Enforced Devices must be compliant and hybrid joined Layer 7 – Continuous Verification ✅ Supported Logs from GSA, Entra, and Intune confirm access decisions 📝 Observations and Lessons Learned
Connector placement is critical — it must reach the target app internally
Avoid wildcard FQDN matches in forwarding profiles; keep scope narrow
Conditional Access must be tested to prevent over-blocking or excessive prompts
Logs from the GSA Portal and Sign-in logs in Entra provide visibility
📌 Project Status
✅ Completed — successfully simulated Entra Private Access configuration to enable Zero Trust access to internal apps
🔜 Next: Project 8 – Configure Entra Internet Access for SaaS Control (placeholder link)