Hello, is anybody else can post it how the edit .plist file should look like and any working workflow f to deployed. I follow up on the @jwojda steps and end up with the packages installed on /private/tmp folder without the script to execute them. Also, the current Team ID and .kext can not bypass the installer Security prompt. I appreciate any help thanks for your efforts and time. Global Protect 5.0.4 version.

After a little bit of digging I was able to figure out how to deploy the portal(s) via configuration profile. I noticed after a fresh install of Global Protect under ~/Library/Preferences, there was a plist called com.paloaltonetworks.GlobalProtect. When I opened it up, it contained a key for Pan Portal List that was set to type array. I added our two portals to the array list & saved the plist. To test, I created a new configuration profile with the custom settings payload configured. Used com.paloaltonetworks.GlobalProtect as the preference domain and then uploaded the plist that I edited. To test, I removed Global Protect, then pushed the configuration profile to my machine ahead of time. Re-installed Global Protect, and as soon as it launched, both of our portals were now pre-populated. Seems that Palo Alto need to update their documentation.

Heres what the general structure of the plist needs to look like:

<?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">
<dict> <key>PanPortalList</key> <array> <string>palo.portal1.com</string> <string>palo.portal2.com</string> </array>
</dict>
</plist>

Hopefully this helps!

Thank you very much coaty.obrien for your responds and efforts, my question here is what option you used when creating the configuration profile with the custom settings, could you give us more details?
And thanks again for your help.

To bypass the security&privacy prompt for latest agent 5.0.5.28 I use; Team ID PXPZ95SK77

Bundle ID kext :
com.paloaltonetworks.kext.pangpd ; com.paloaltonetworks.GlobalProtect.gpsplit ;
com.paloaltonetworks.GlobalProtect.gplock

I am stuck in the connecting loop... I've got the portal to load correctly via but now when it opens it is just stuck in the connecting loop. I've tried pushing the launch d with launchctl which used to work but I can't get it to work anymore... Can anyone shed some light onto this?

@sintichn we had a similar issue with the new version on Mojave and the then Catalina. I am thinking you are in a security check loop. If you go to System Preferences and then Security and Privacy on one of the machines with the issue, you should see a security confirmation dialogue. This is similar to the non-certified App installation dialogue.

The way we got around this was a Kernel Extension with the following info:
Display Name: Palo Alto Networks
Bundle ID: PXPZ95SK77

Deploy globalprotect but software is using the administrator credentials to connect instead of using the user credentials to connect.

So I finally got this to work in my environment. I kept running into the issue of the connecting loop. This is what I did...
- I started to build a DMG for GlobalProtect in composer by way of a normal snapshot
- Next before building the DMG I edited the two launch agent plist files in /Library/LaunchAgents com.paloaltonetworks.gp.pangps.plist, com.paloaltonetworks.gp.pangpa.plist Taking out the LimitLoadToSessionType key and string Aqua in both plist files. (https://www.jamf.com/jamf-nation/discussions/29172/installing-globalprotect-4-1-3-vpn-client)
- Then in /Users/currentuser/Library/Preferences I put the portal address in the com.paloaltonetworks.GlobalProtect.plist.

<key>PanPortalList</key><array><string>yourportalhere</string></array>

- Then I built the DMG uploaded it to jamf admin and checked FUT and FEU
- When creating a policy I added two scripts, one to run before the DMG is installed and one after. The before script is just to stop the GlobalProtect process if it's running.

#!/bin/sh
killall GlobalProtect

The the one that runs after is...

#!/bin/sh
# Finds the logged on user
USER_NAME=$(printf '%s' "${SUDO_USER:-$USER}")
# Opens the updated GlobalProtect app
 open /Applications/GlobalProtect.app
# Waits 5 seconds
 sleep 5
# Uses the logged in user to load the LaunchDaemon via launchctl
sudo -u $USER_NAME launchctl load /Library/LaunchDaemons/com.paloaltonetworks.gp.pangpsd.plist
echo "done"

(This doesn't work unless the launchctl line is run as the current logged in user, thus the $USER_NAME parameter.)

And finally, it works!

@sintichn

You could just deploy your plist settings at a system level with a script and then push out the native GlobalProtect package. This is what we're doing and seems a little cleaner than a custom package with FUT and FEU.

Here is an example setup script based on what I've been doing. GlobalProtect doesn't appear to respect these settings if deployed with a Configuration Profile so a script is required from what I've seen.

#!/bin/bash

plistBuddy='/usr/libexec/PlistBuddy'
GPplistFile='/Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist'

if [[ -f ${GPplistFile} ]]; then
  echo "Removing existing GlobalProtect prefs file"
  rm -f ${GPplistFile}
fi

${plistBuddy} -c "print : 'Palo Alto Networks':'GlobalProtect':'PanSetup':'Portal'" ${GPplistFile}

${plistBuddy} -c "add :'Palo Alto Networks' dict" ${GPplistFile}
${plistBuddy} -c "add :'Palo Alto Networks':'GlobalProtect' dict" ${GPplistFile}
${plistBuddy} -c "add :'Palo Alto Networks':'GlobalProtect':'PanSetup' dict" ${GPplistFile}
${plistBuddy} -c "add :'Palo Alto Networks':'GlobalProtect':'PanSetup':'Portal' string 'vpn.example.com'" ${GPplistFile}
${plistBuddy} -c "add :'Palo Alto Networks':'GlobalProtect':'PanSetup':'Prelogon' integer 1" ${GPplistFile}

@cbrewer Thanks so much, this works well!

Anyone have a EA to get the VPN IP address the client is on when connected via GP?

@cbrewer We just switched to GlobalProtect and this worked like a charm. Thanks!

I am fully stuck on this one. I have deployed the pkg and plist as recommended by @cbrewer and that part works like a champ. I still get stuck at the connecting loop. I've deployed the kext multiple times multiple ways with no luck. The latest is shown below. I took it and deployed it via JAMF but with those settings. That is directly from their website. Any help would be much appreciated!

@ncottle ,

We have this all the time and it has been a continuous issue. Most of the time, killing the client and allowing it to relaunch automatically gets around this. What happens when you run the below in Terminal:

sudo killall GlobalProtect

On a related note, has anyone gotten GlobalProtect v5 working in Catalina? This is the officially supported version and we are continuously seeing a (false) "Cannot connect to gateway" error, even though the client connects just fine.

I know v4 is not officially supported in Catalina but it seems to work fine, and to me is a better solution than deploying a broken client. Has anyone validated 4.1.13 in Catalina?

Thanks,
Justin.

5.1.1 working fine in Catalina here.

Anytime you do things with command line or scripts related to GlobalProtect, you want to be aware of which user you are running that task as. GlobalProtect has both a system LaunchDaemon as well as user level LaunchAgents. Here is the script I use to make sure GlobalProtect is started correctly for the logged in user. I run this after installation.

#!/bin/bash

# Make sure GP is installed
if [[ ! -d /Applications/GlobalProtect.app ]]; then
  echo "GlobalProtect not installed"
  exit 0
fi

# Get logged in user
loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )

# Stop GlobalProtect Services
if [[ -n ${loggedInUser} ]]; then
  if [[ -f /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plist ]]; then
    echo "Attempting to stop com.paloaltonetworks.gp.pangpa"
    su -l $loggedInUser -c "/bin/launchctl unload /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plist"
  fi
  if [[ -f /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist ]]; then
    echo "Attempting to stop com.paloaltonetworks.gp.pangps"
    su -l $loggedInUser -c "/bin/launchctl unload /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist"
  fi
fi

if [[ -f /Library/LaunchDaemons/com.paloaltonetworks.gp.pangpsd.plist ]]; then
  echo "Attempting to stop com.paloaltonetworks.gp.pangpsd"
  /bin/launchctl unload /Library/LaunchDaemons/com.paloaltonetworks.gp.pangpsd.plist
fi

sleep 3

# Start GlobalProtect Services
if [[ -f /Library/LaunchDaemons/com.paloaltonetworks.gp.pangpsd.plist ]]; then
  echo "Attempting to start com.paloaltonetworks.gp.pangpsd"
  /bin/launchctl load /Library/LaunchDaemons/com.paloaltonetworks.gp.pangpsd.plist
fi

if [[ -n ${loggedInUser} ]]; then
  if [[ -f /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist ]]; then
    echo "Attempting to start com.paloaltonetworks.gp.pangps"
    su -l $loggedInUser -c "/bin/launchctl load /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist"
  fi

  if [[ -f /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plist ]]; then
    echo "Attempting to start com.paloaltonetworks.gp.pangpa"
    su -l $loggedInUser -c "/bin/launchctl load /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plist"
  fi
fi

@cbrewer ,

Thanks for this. Our issue appears to be related to the encryption/decryption of cookies at appliance level.

Regarding the logged in user, we avoided this whole situation by not touching the installer package and adding our pre-configuration as a separate package in the same policy.

We found that modifying the package in any way resulted in a failed installation, so the above makes total sense.

Thanks,
Justin.

Thanks for the updates everyone. I've tried it all and still no luck. I think I've narrowed it down to either a firewall or a kext issue. Attempting to work without network team to address that side of it now.

Try enabling debug logging under Settings > Troubleshooting. That will get you a complete dump of all applicable logs and make it easier to identify the issue.

I anybody just doing a wipe and pave for updates?

@cbrewer Thanks! This product is a nightmare to deploy!

I am in the same boat as @jared_f and curious how people are handling GlobalProtect updates.

We recently deployed Global Protect, how often are updates pushed?

As for our deployment I pushed the KEXT a few days prior and then began the software deployment. We haven't seen any issues deploying. We also did not push a .plist with the portal url baked in.

GlobalProtect 5.1.2 appears to have resolved some of the issues around starting the services as the currently logged in user when deployed from Jamf.

Fixed an issue in GlobalProtect for macOS endpoints where installing or upgrading the package using a Mobile Device Management (MDM) solution such as JAMF Pro resulted in a GlobalProtect app initialization failure.

We were having the Connecting Loop issue while trying to deploy GlobalProtect 5.1.3. I ended up having to use composer to package placing the installer in a Jamf folder I created in the Root Library. I then used a script to run the installer followed up by @cbrewer script above to create a plist with our portal and it worked perfectly. Now for updates I just need to update the installer.

I had been fighting several issues with versions 5.1.2 and 5.1.3. Finally they released version 5.1.4 and it appears most of the issues have been resolved, production rollout it is...

@smpotter just a regular package created with 5.1.4?