This blog covers a custom script solution for Intune, that can be used to automatically detect, if the Entra Private Access (GSA) client is connected to the internal network – or off-site. When the client is connected to the internal network, we don’t want to send the network traffic into the GSA tunnel through Microsoft – but use direct connectivity to the servers.

Scripts can be used in Intune with the necessary scripts (detection, remediation, suspension). Scripts can serve as a workaround until Microsoft releases support for this in the Entra GSA client.

Update Aug 23, 2023 - Method #1 (Resolve_DNSName-Validate_Against_IP)
I have added a parameter $FailoverTargetIP to method #1, which solves a problem, if the EPA client gets into a wrong state, which can result in DNS lookup not working against an internal DNS server. I have seen this, when EPA client was connected to an 802.1x environment with the EPA client ON, but network was blocking DNS traffic to DNS server as it was coming through the tunnel. Ping was working, but no DNS lookup. Initially it will try to do a DNS lookup. If it fails, it will fall over to do a ping against an internal IP for example the app-proxy server.

$Mode                    = "Resolve_DNSName-Validate_Against_IP"
$Target                   = "GSA-TEST.xxxxxx"
$ExpectedResult   = "172.22.0.1"
$FailoverTargetIP = "172.22.0.11"

---------

V2-Update - Entra GSA v2.0
This blog has been updated to include new features in Entra GSA v2.0 (released July 2024). My scripts has also been updated as promised and works with the new features.

The updated scripts will only work for Entra GSA client version 2.0+, which can be downloaded here. 

You can always get the latest Entra GSA version using this link https://aka.ms/gsawinlatest

You can read about the changes later in this blog - click here for shortcut to section

V2 changes:
* Support for new reg-key in v2.0 ""

Background

As part of the implementation of Entra Private Access, you define your internal networks in the Entra Private Access solution. Then the agent knows which networks / FQDNs to “tunnel” through the agent. This is very cool, when you are sitting home, at guest networks, hotels, etc.

But when you are sitting onsite close to the servers (internal network), you don’t want the traffic to go through the tunnel, but directly through the local network. Your users will appreciate you for this improvement 🙂

Solution

On my Github, I have provided 3 scripts, that can be used to solve this problem.

My script will be updated according to the below mentioned steps.

Timing	Functionality
June 2024	Script (v1 script – can be found here) will stop/start Windows service for Entra GSA client (3 services), which will impact all client functionality (Private Access, Internet Access)
July 2024	My current script (v2) has been adjusted. Now only Entra Private Access will be suspended/started, so Entra Internet Access functionality is not impacted. You find the current (updated) remediation script here
2H- 2024	Entra Private Access “Intelligent local access” feature built into product

Support for Entra GSA v2.0 features (July 2024 release)

Entra GSA client v2.0+ does now support 2 new reg-keys that allows more flexibility around stop/start of Entra Private Access. My script (v2, current version) supports these features.

V2 Feature – Stop/Start Entra Private Access functionality dynamically using regkey

You can dynamically control the state of Entra Private Access functionality by setting the key IsPrivateAccessDisabledByUser in registry path HKCU\Software\Microsoft\Global Secure Access Client

Path	Key	Value (DWORD)
HKCU\Software\Microsoft\Global Secure Access Client	IsPrivateAccessDisabledByUser	0 = Private Access is Active 1 = Private Access is Suspended

V2 Feature – Allow User to stop/start Entra Private Access functionality manually

You can allow a user to control Entra Private Access functionality by setting the key ‘HideDisablePrivateAccessButton‘ in the path HKLM\Software\Microsoft\Global Secure Access Client

Path	Key	Value (DWORD)
HKLM\Software\Microsoft\Global Secure Access Client	HideDisablePrivateAccessButton	0 = User is allowed to start/stop Entra Private Access 1 (or no key) = User is not allowed to control stop/start

New detection features in v2 script

Thank you for the questions and feedback to extend the detection method.

v2 of my remediation script (link to Github) includes 3 methods for local network detection. . Hope the new features can support your needs.

Method #1 - Resolve_DNSName-Validate_Against_IP - Local DNS Name lookup - result should respond to IP addr
NOTE: Requires local DNS solution like Windows AD DNS, InfoBlox, Router DNS, etc.

        $Mode                                = "Resolve_DNSName-Validate_Against_IP"
        $Target                               = "DC1.2linkit.local"
        $ExpectedResult               = "10.1.0.5"

------------------------------------------------------------------------

Method #2A - Ping_DNSName-Resolve_DNSName_To_IP - IP address reverse lookup - result should respond to DNS hostname address - use specific DNS server

NOTE: This DNS domain cannot be inside Private Access tunnel. Must be an external zone used locally
Reason: Entra Private Access treats any hosts names part of Private DNS-functionality as wildcards, so it will  respond with an internal tunnel IP when client is running

        $Mode                                = "Ping_DNSName-Resolve_DNSName_To_IP"
        $Target                               = "10.1.0.5"
        $ExpectedResult               = "DC1.2linkit.local"
        $DNSServerIP                    = "10.1.0.5"

------------------------------------------------------------------------

Method #2B - Ping_DNSName-Resolve_DNSName_To_IP - IP address reverse lookup - result should respond to DNS hostname address - use DNS from IP/DHCP settings on client

NOTE: This DNS domain cannot be inside Private Access tunnel. Must be an external zone used locally
Reason: Entra Private Access treats any hosts names part of Private DNS-functionality as wildcards, so it will respond with an internal tunnel IP when client is running

        $Mode                                = "Ping_DNSName-Resolve_DNSName_To_IP"
        $Target                               = "10.1.0.5"
        $ExpectedResult               = "DC1.2linkit.local"
        $DNSServerIP                    = $null

------------------------------------------------------------------------

Method #3 - Ping_IP-Validate_MACAddr_Against_ARP_Cache - Ping IP addr and validate MAC address matches the expected result

NOTE: Method can typically only be used when device is on same subnet as target IP device fx. router (switched
network). This method can easily be extended into an array covering all local sites, but it must be manually maintained

        $Mode                                = "Ping_IP-Validate_MACAddr_Against_ARP_Cache"
        $Target                               = "192.168.1.1"
        $ExpectedResult               = "d2-21-f9-7e-82-86"

Requirement to use V2 features

You need to update your Entra GSA client to v2.0+. You can always get the latest version using this link https://aka.ms/gsawinlatest

The updated scripts part of this blog will only work with Entra GSA client version 2.0+

Scenario: Computer is NOT connected to internal network – it can NOT do NSLOOKUP of DNS record

Result: GSA client is started

Scenario: Computer is connected to internal network – it can do NSLOOKUP of DNS record

Result: GSA is stopped

Suspension of behavior once in production

Suspension of script-behavior is built into the remediation-script, in case of rogue network detection or user wants to override.

In advance, you can prepare the suspension-script in Intune, so you quickly can activate it for a single user or multiple users. Basically it sets a reg-key.

Implementation

Using Intune Proactive Remediations, you can implement the detection and remediation scripts. Of course you want to test it before uploading to Intune 🙂

Please adjust the following parameters in the remediation script:

##################################
# VARIABLES
##################################

$Internal_DNSRecord_Name = "<put in your DNS record here>"
$Internal_DNSRecord_Expected_Response = "<put in the expected IPv4 address here>"

$RerunEveryMin = 1

$RerunNumberBeforeExiting = 59
# When it hits the number, it forces script to Exit 1. It must be less than 1 hr, as remediation job kicks off hourly


$RerunTesting = $False
# If $true it will force script to run every 2 sec. If $False, if uses $RerunEveyMin

Based on the values above, the script runs every 1 minute with 59 runs and then it terminates. The remediation script should run hourly. Feel free to fine-tune to your needs of how often you want the script to wait/run.

NOTE:
The updated V2 script must run in the context of the user, so below setting 'Run this script using the logged-on credentials' must be set to YES.