Last year I wrote a blog article about Microsoft Global Secure Access and what kind of services it provides. Therefore, I decided to write an example about use-cases for it in preparation for a session I have tomorrow Agenda – xenappblog you can also view the PPT here –> community/GSA-MariusSandbu.pptx at main · msandbu/community (github.com)
One thing that is missing in Microsoft Azure today in the networking stack is a “true” optimal Zero-trust network access (as seen from the CISA Zero-Trust framework screenshot below). Today we have the option to route traffic from one service to another to a Network Appliance (such as 3.party) or Azure Firewall or using built-in capabilities such as NSGs or ASGs. All these features are looking more at the incoming traffic where you have predefined rules at either layer 4 or layer 7 depending on if you use firewalls. However, few of these services validate the health of the endpoint and can enforce MFA requirements for a client that want to communicate with a service.
So enter Global Secure Access – Private Access. In the simplest terms it is a modified version of the former Azure Application Proxy. The former version of App Proxy had the limitation that it only supported services via HTTP, while the new service supports all TCP based services.
The traffic flow for a service looks like this.
1: User initiates traffic to a service/application that is publised trough Global Secure Access
2: GSA Client checks if a forward profile is enabled and if the application/service has a defined route (IP or FQDN)
3: GSA Evaluates with Entra ID any Conditional Access policies that is defined for the service.
4: Conditional Access initiates authentication context with the user (such as MFA prompt)
5: After successfully validated against Policies, the GSA agent will route traffic to the Entra ID Private Access PoP (Point of Presence)
6: The App Proxy service pulls out traffic (R-TCP) which is being queued in the service and routes traffic to the service.
So essentially, the app proxy server (which unfortunately needs to run Windows Server) establishes communication with the backend service, which can be fileservers, RDP or even web service running as a private endpoint in Azure. NOTE: The App proxy can run anywhere, it’s not limited to run in cloud, but you should ensure where the closest PoPs (Global Secure Access points of presence – Global Secure Access | Microsoft Learn) are since this service will increase the latency between the client and the backend service since Pop’s might be far away and secondly how it routes traffic via R-TCP.
Now for one customer that I am working with now, we were exploring if we could use this service (even if it is still in preview) to ensure that users could access internal services in Azure such as Private Endpoint in a secure manner from the endpoints to allow ease of management and even higher security. (As seen in the screenshot below)
What we did was to set up some example private endpoint services in a VNET which the end-users did not have access too, from their AVD machines or their regular Windows clients. Within the VNET we also set up a virtual machine running Windows Server and an Azure App Proxy Connector as part of Private Access.
Then we ensure that traffic forwarding for private access was enabled.
Published an Enterprise app and defined the FQDN of the DNS name and pointed it to the correct IP address. In this example it is pointing to an Azure OpenAI service which is only enabled with private access. I have a test users access via Users and Groups and then lastly made a Conditional Access policy to require MFA authentication for access to this application.
The FQDN was the public URL of the OpenAI service, which would be resolved by the App proxy connector which will in turn point to the CNAME which is the internal service.
When the user wants to access Azure OpenAI from their machine without using the GSA Client they will get the following error message in the Azure Portal.
When we activate the GSA client and ensure that the profile is enabled with applications (you can also verify this in the client) the client will verify that you are trying to reach that FQDN and will trigger the authentication flow
- Does not fully support IPv6
- WILL ADD ADDITIONAL LATENCY
- Does not support DoH (DNS-Over-HTTPS)
- Does not support UDP for internal services (yet…)
- For instance QUIC protocol needs to be blocked
- Can support Entra ID B2B If device is home to the main Entra ID Tenant
- Single label domains are not supported
- For instance https://service01
- Tunneling traffic by IP Address requires that the IP Ranges are outside of the end-user device local subnet
- Remember that Apple devices do not support routing traffic with services that end with .local
- Apple devices might not open your internal network’s ‘.local’ domain – Apple Support
However earlier this month, some new services were launched into preview (yay!) and you can apply for access to the new features here –> Microsoft Entra Private Access VPN replacement private preview interest form (office.com)
This blog is part of Microsoft Azure Week! Find more similar blogs on our Microsoft Azure Landing page here.
About the author:
Cloud Evangelist at Sopra Steria | Office of the CTO | Podcaster @Cloudfirstpodcast | Author | Public Speaker
Reference:
Sandbu, M. (2024) ZTNA for Azure Private Endpoint using Entra Private Access. Available at: ZTNA for Azure Private Endpoint using Entra Private Access – msandbu.org [Accessed on 24/06/2024]
