Anyone deployed Palo Alto GlobalProtect?

stevehahn
Contributor

My searches have turned up nothing. Just looking for gotchas, do's and don'ts, etc.

108 REPLIES 108

ktanaka
New Contributor

Issue 1: I am running into an issue with 5.1.4 where after it installs it prompts the user to allow it in SysPref>Security despite us deploying a kext/sysext profile a couple versions ago.

Issue 2: On a company configured device: If the user never allows the app it still functions. But after allowing, the user receives a prompt to allow GlobalProtect to add a VPN Configuration. This prompt pops up EVERY time it connects to VPN whether the user chose to Allow/Don't Allow on the previous connection. Company devices are set up with the old CIS benchmarks from High Sierra. Anyone know of a setting in CIS benchmarks that could be causing this? (Our InfoSys team hasn't given us an updated policy for Catalina CIS Benchmarks.)

On a personal device: after allowing the configuration it saves and uses it to connect on future connections.

f5ef20f011ca46868aa0ca45cbd6d2f1

d588a96578b343f88bb4eb8c7f65ff40

mas19
New Contributor

Hi. In Test, we have upgraded GlobalProtect from v5.0.4 to v5.1.4. This upgrade is being delivered from JAMF Pro and works as should. However, on the client side after the update, the following prompts appear:
39cbb06c96d44956a84094dc099d1ce2
9f3389230f354e7bb827b7f9fc0c9fa1
132217e00d4f4623948edd413047b473
8d1e8227b01242568d6f06e5b5bdf524

The Keychain pop-up prompts appears last 3476820d23504981b989b962eea6923f
How do I use System Extensions in JAMF Pro to pre approve GlobalProtect v5.1.4 program as a whole so that the end users do not need to interact with these prompts?

Gonzalez
New Contributor III

@mas19 We push a configuration file to set our VIP portal address (although this requires as script.) Along with it the Kernel Extension. And finally the PPPC permissions that will allow access to the folders. ![optional image ALT text](
cc02b04952034f72bfd981c93c8899cc
)

mas19
New Contributor

@Gonzalez This put me and others into the right direction. Since being a newbie, we already had the Kernel Extensions created for previous versions of GlobalProtect. For the new version of 5.1.4, we enabled Systems Extensions due to going forward with Catalina requirements. On your payload for Application & Custom settings, curious to know your settings to see if it would be applicable. Thanks again sir!

ablend
New Contributor III

@mas19 I'm seeing the same thing. I have two different PPPC profiles. One matches the previous (up to 5.1.4) binary identifier "com.paloaltonetworks.GlobalProtect" and one with the new (5.1.4 and newer) identifier "com.paloaltonetworks.GlobalProtect.client" allowing access to the user's Desktop / Documents / Downloads folder, and the prompts still pop up when upgrading from 5.0.x to 5.1.4 (or 5.1.5). It's not obeying the profile, as best I can tell. I have a ticket open with Palo Alto but no progress to report.

I'd like to request anyone else with similar issues please open a ticket with PA so we can get some traction on this collectively.

tep
Contributor II

@mas19 I am having the same issue and opened a ticket with PAN - no really luck getting them to help though.

ablend
New Contributor III

It appears the problem is the change in the bundle identifier for an existing application in Catalina. If GlobalProtect is installed with the 5.0.x and previous bundle identifier of "com.paloaltonetworks.GlobalProtect" then is updated to 5.1.x and the new bundle identifier is "com.paloaltonetworks.GlobalProtect.client", the user is prompted regardless of what PPPC profiles are in place. That same behavior does not exist in Mojave.

However, if you uninstall GP 5.0.x then install GP 5.1.x, it obeys the PPPC profile and the user doesn't see anything. So it looks like we might need to be raising tickets with Apple rather than Palo Alto. I understand the logic behind wanting the user to "acknowledge" when a bundle identifier changes for security, but there needs to be some kind of an exclusion for when that new ID matches MDM delivered PPPC profiles.

NOLA2ATX78
New Contributor II

Here is the official response from Palo Alto engineering:
As per our engineering team there is no way to block the pop up from showing multiple times. This is an MAC OS related issue and GP cannot fix this. Following is an explaination provided by our engineering team.

If using the System keychain, there is no "Always Allow" button in pop-up dialog, the system API will trigger the pop-up every time when a new connection is establishing. Sometime System keychain is in "Locked" status for GP process, GP will call some system API to "Unlock" it to retrieve info. In this case, there will have one more pop-up. Basically it's system behavior and GP cannot control it.

tep
Contributor II

I've been removing 5.0.x before the install of 5.1.x but not scoping any config profile changes....I've just been adding the "com.paloaltonetworks.GlobalProtect.client" PPPC profile for all the macs I'm testing on.

Gonzalez
New Contributor III

@mas19 While a pain... you may be able to use the security command to open the system keychain and avoid one of the prompts. Thanks to all for the update on the bundle identifier. A question from me, how did you get the Jamf policy to install the system extension. Using the pkg file provide by our network team I can only get the basic VPN client to install. Unless I manually run the installer?

tep
Contributor II

FWIW, I did add a line to my install script to delete all the remaining keychain items and now I just get the dumb PPPC prompts. The function, in case anyone is interested:

RemoveGPKeychainItems () {
# Look for GP keychain items and delete them to avoid pop-ups
    if [[ `/bin/launchctl asuser $userid /usr/bin/security find-generic-password -l GlobalProtectService $userKeychain` ]]
        then
            echo "found GlobalProtectService keychain item, deleting"
            /bin/launchctl asuser $userid /usr/bin/security delete-generic-password -l GlobalProtectService $userKeychain
    fi
    if [[ `/bin/launchctl asuser $userid /usr/bin/security find-generic-password -l GlobalProtect $userKeychain` ]]
            then
                echo "found GlobalProtect keychain item, deleting"
                /bin/launchctl asuser $userid /usr/bin/security delete-generic-password -l GlobalProtect $userKeychain
        fi
}

jerrymo
New Contributor

@tep what's your $userid and $userKeychain variable pointed to?

tep
Contributor II

@jerrymo

CURRENTUSER=$(/bin/echo "show State:/Users/ConsoleUser" | /usr/sbin/scutil | /usr/bin/awk '/Name :/&&!/loginwindow/{print $3}')
userid=$( /usr/bin/id -u $CURRENTUSER )
userKeychain=/Users/$CURRENTUSER/Library/Keychains/login.keychain

smpotter
New Contributor III

Has anyone else seen this issue with GlobalProtect? It usually occurs after a restart...

GlobalProtect version = 5.1.5
bfecd06f64f6408695da8239cc4ebf3b

Gonzalez
New Contributor III

@smpotter This seems to be resolved by version 5.2 or greater.

hstanley
New Contributor III

@Gonzalez Were you able to find a way to get the Jamf policy to install the system extension? I saw your previous post from 7/20/2020 about that, and I'm running into the same issue. I'm only getting the basic VPN client to install. Curious if you found a way.

dan-snelson
Valued Contributor II

Happy Thursday, @jkryklywec! Did you ever pull off an EA for the VPN IP of GlobalProtect?

Gonzalez
New Contributor III

@hstanley A member of the Macadmins Slack group posted the solution. There is a script that is included and needs to run. I've included the following in a script that runs before the package install with a couple of commands to ensure plist and other workarounds.

out_dir="/Library/Logs/PaloAltoNetworks/GlobalProtect" pan_info() { curtime=date echo $curtime " " $1 >> ${out_dir}/PanGPInstall.log } pan_info "Install system extensions after installation" sudo mkdir -p "/Library/Application Support/PaloAltoNetworks/GlobalProtect" sudo touch "/Library/Application Support/PaloAltoNetworks/GlobalProtect/install_system_extensions.now"

dan-snelson
Valued Contributor II

@jkryklywec With assistance from @franton, we're testing the following EA for both AnyConnect and GlobalProtect

#!/bin/sh
# Extension Attribute to read the IP address of the active VPN connection

anyConnectTest="/opt/cisco/anyconnect/bin/vpn" # Cisco binary
globalProtectTest="/Applications/GlobalProtect.app/Contents/Resources/PanGPS" # GlobalProtect binary

###
# Cisco AnyConnect
###

if [ -f "${anyConnectTest}" ] ; then

    # Cisco AnyConnect installed; read current IP Address
    anyConnectIP=$(/opt/cisco/anyconnect/bin/vpn stats | grep "Client Address (IPv4):" | awk '{print $4}')

    if [ "${anyConnectIP}" = "Not" ]; then
        # IP address is blank, report no connection
        anyConnectStatus="AnyConnect IP: Inactive"
    else
        # IP address is *not* blank, report the IP address
        anyConnectStatus="AnyConnect IP: ${anyConnectIP}"
    fi

else

    # Cisco AnyConnect is not installed
    anyConnectStatus="AnyConnect not installed"

fi



###
# Palo Alto Networks GlobalProtect
# Thanks, @franton!
###

if [ -f "${globalProtectTest}" ] ; then

    # Palo Alto Networks GlobalProtect installed; read current IP Address
    if [ -z "$( ifconfig | grep -E "gpd|utun2" | grep "UP" )" ]; then
        globalProtectStatus="GlobalProtect IP: Inactive"
    else
        globalProtectStatus="GlobalProtect IP: $( ifconfig | grep -A2 -E "gpd|utun2" | grep inet | awk '{ print $2 }' )"
    fi

else

    # Palo Alto Networks GlobalProtect is not installed
    globalProtectStatus="GlobalProtect not installed"

fi

echo "<result>$anyConnectStatus
$globalProtectStatus</result>"



exit 0

sdagley
Esteemed Contributor II

@dan-snelson There may be some variation on what utun instance you want to check for the GlobalProtect assigned IP address. On my test system utun0 is what corresponds to the IPv4 address displayed in the GlobalProtect GUI as the assigned local IP. This is with GP version 5.2.4

dan-snelson
Valued Contributor II

Thanks for the heads-up, @sdagley!

jkryklywec
New Contributor III

@dan-snelson
will check it out, i actually had 2 EA for GP one for versions less than v5.14 looking in GPD0 and for v5.14 and greator using utun2
but your script merges both of those ! awsome

dan-snelson
Valued Contributor II

Happy Wednesday, all!

I need to more carefully review @cbrewer's script; we're currently testing the following Files and Process > Execute Command in our install policy for GlobalProtect 5.1.7-20 to ward off the dreaded "Connecting…" post-install:

loggedInUser=$( /bin/echo "show State:/Users/ConsoleUser" | /usr/sbin/scutil | /usr/bin/awk '/Name :/ && ! /loginwindow/ { print $3 }' ) ; loggedInUID=$( /usr/bin/id -u "$loggedInUser" ) ; /bin/launchctl kickstart -kp gui/${loggedInUID}/com.paloaltonetworks.gp.pangpa ; /bin/launchctl kickstart -kp gui/${loggedInUID}/com.paloaltonetworks.gp.pangps

jwojda
Valued Contributor II

what's the easiest way to Deploy Global Protect with the system extensions if required? Just pushing the base package out doesn't seem to select them by default. Would it be Choices.XML file then? If so, does anybody have a pre-made one before I go down the road if creating a new one?

What about systems that dont use SysExt? Would it still be safe to install them? Otherwise I would assume a separate installer would be needed.

sdagley
Esteemed Contributor II

@jwojda My experience is that GlobalProtect 5.2.3 and later automatically install the System Extension on macOS Catalina and Big Sur when initiating a connection if it wasn't installed when the .pkg installer was run. If you have a Configuration Profile in place approving the System Extension when that happens there should be no user prompting.

franton
Valued Contributor III

@jwojda I'm using the installer choice changes method to enforce it. I'm lucky in that my estate can actually deal with it nicely.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <array> <dict> <key>attributeSetting</key> <integer>1</integer> <key>choiceAttribute</key> <string>selected</string> <key>choiceIdentifier</key> <string>default</string> </dict> <dict> <key>attributeSetting</key> <integer>0</integer> <key>choiceAttribute</key> <string>selected</string> <key>choiceIdentifier</key> <string>second</string> </dict> <dict> <key>attributeSetting</key> <integer>1</integer> <key>choiceAttribute</key> <string>selected</string> <key>choiceIdentifier</key> <string>third</string> </dict> </array> </plist>

davidjess
New Contributor III

Hi folks, sdagley asked me to post in this discussion.

Looking in to upgrading to GPVPN 5.2.3 from 5.0.5 at the moment, so having to update some of our scripts from gpd0 to utun. Problem being which utun interface is used by ifconfig to show whether the connection is active or not seems to change from machine to machine.

In our environment, ifconfig doesn't return any other lines with either "flags=8050" which the selected interface will return if it's disconnected. And it also doesn't return "-->" which it will return in the line with your IP address. So if those statements are both true in your environment, you could use this EA to show whether GPVPN is connected, and if so, the IP address.

#!/bin/bash

GP_Status=$(ifconfig | grep "flags=8050")
GP_IP=$(ifconfig | grep -e "-->" | sed 's/|/ /'|awk '{print $2}')
if [[ -n "$GP_Status" ]]; then GP_Status_Check="Not Connected" /bin/echo "<result>$GP_Status_Check</result>" /bin/echo "$GP_Status"
else GP_Status_Check="Connected" /bin/echo "<result>$GP_Status_Check - $GP_IP</result>"

fi

davidjess
New Contributor III

Also, while I'm at it. Here's an EA to check whether or not a machine is on a compatible version. This is probably easier to do in python, but I'm crap at python, so there's some logic to do the floating point comparison in bash and mark any version above your defined version as compatible.

#!/bin/zsh

# Global Protect Version Compare
# This EA compares two versions of Global Protect. It takes the version currently installed, and a version specified
# Under 'APPROVEDVERSION' at the top of the script. It removes the decimal points from each version number to 
# allow zsh to compare the two numbers without floating points (which it can't do accurately) then removes all
# but the first three digits of the version number, because we know the formatting of Global Protect versions
# EG the installed version is 1.2.3-45 and the approved version is 4.5.6-78 it would reduce these numbers to 
# 123 and 456 and see that the installed version is lower than the approved version. There are three possible 
# outputs to this script: 
# Compatible - if the installed version is equal to or greater than the approved version.
# Old (with version no) - if the installed version is less than the approved version
# Not Installed - Global Protect not installed
# NB this script only works where the major version of the software release is in the first 3 digits, you can adjust
# this by changing the number in the second sed in lines 21 and 22

APPROVEDVERSION=5.2.3-22
INSTALLEDVERSION=$(defaults read /Applications/GlobalProtect.app/Contents/Info.plist CFBundleShortVersionString)

if [ -f "/Applications/GlobalProtect.app/Contents/Info.plist" ] ; then
    INSTVERSION=$(echo "$INSTALLEDVERSION" | sed 's|[.]||g' | sed -E 's/(.{3}).*/1/')
    APPVERSION=$(echo "$APPROVEDVERSION" | sed 's|[.]||g' | sed -E 's/(.{3}).*/1/')


if [[ $INSTVERSION -ge $APPVERSION ]]; then
            echo "<result>Compatible</result>"
        else
            echo "<result>Old - $INSTALLEDVERSION</result>"
        fi
else
        echo "<result>Not Installed</result>"

fi

sdagley
Esteemed Contributor II

Tangential to the EA that @davidjess posted above here is an EA that just returns the GlobalProtect app version string with the "-" (which I presume is used to separate the Build number from the Version number) with a "." so that you can use a regex generated by @talkingmoose's Match Version Number or Higher or @hsucmoore's make_ge_version_regex.bash scripts in a Smart Group criteria to evaluate the version installed on a machine:

#!/bin/sh

# EA - Get GlobalProtect Version
#
# GlobalProtect uses a version number in the format X.X.X-X which doesn't work
# with the Match Version Number or Higher.bash or make_ge_version_regex.bash scripts to
# generate regex expressions to evaluate version numbers in the form of X.X.X.X.
#
# This EA simply reads the CFBundleShortVersionString info from the GlobalProtect app
# if it's installed and replaces any - in that string with a .

result="Not Installed"
PListToCheck="/Applications/GlobalProtect.app/Contents/Info.plist"

if [ -f "$PListToCheck" ] ; then
    GPVersion=$( /usr/bin/defaults read "$PListToCheck" CFBundleShortVersionString )

    if [ -n "$GPVersion" ]; then
        result=$(/bin/echo $GPVersion | /usr/bin/tr '-' '.')
    fi
fi

echo "<result>$result</result>"