Help with configuration profile for GlobalProtect

Hello,

I use a script to accomplish this, please edit the portal address and the script will take care of the rest.

#!/bin/sh

#
# Set the portal address for GlobalProtect
#

portalAddress="LINKGOESHERE"

#
# Modify PLIST to reflect the correct portal address.
#

echo '<?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>Palo Alto Networks</key><dict><key>GlobalProtect</key><dict><key>PanSetup</key><dict><key>Portal</key><string>'$portalAddress'</string><key>Prelogon</key><integer>0</integer></dict></dict></dict></dict></plist>' >> /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist

This is what we use for our config profile. Granted, we have two separate portals, so we use an array.

<?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>vpn1.server.com</string>
        <string>vpn2.server.com</string>
    </array>
</dict>
</plist>

In our deployment, we pushed out /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist which contains portal address. However, we also needed to remove user config files in all existing user home folders:

#!/bin/sh
 rm -rf /Users/*/Library/Application Support/PaloAltoNetworks/GlobalProtect
 rm -rf /Users/*/Library/Preferences/com.paloaltonetworks.GlobalProtect*
 rm -rf /Users/*/Library/Preferences/PanGPS*

Otherwise the user config files seem to override the system library file.
Uninstalling GlobalProtect only removes the config files in current console user profile folder.

So, what I did was upload a working plist file to a Computer level Configuration Profile with the "Preference Domain": com.paloaltonetworks.GlobalProtect

I have recently found that switching to a different portal (we have several VPNs for different users) will not take the new domain without doing a complete uninstall and reinstall. I found these instructions on the PaloAlto site.:

1. Uninstall the GlobalProtect App for Mac.
2. Determine if the GlobalProtect enforcer kernel extension exists on the endpoint. • On the Mac endpoint, open the Terminal application under the Applications/Utilities folder, and then enter the following command: • kextstat | grep gplock
3. If the extension exists, unload the enforcer. • Enter the following command on the Terminal application to unload the enforcer: • sudo kextunload -b com.paloaltonetworks.GlobalProtect.gplock
4. Prevent the enforcer from reloading after a reboot. • Enter the following command on the Terminal application to remove the enforcer from the Mac hard disk: • sudo rm -r "/System/Library/Extensions/gplock*.kext"
5. Download and Install the GlobalProtect App for Mac.

So I have a GP remove policy that runs the following script and then calls the Global Protect installer once the new Profile is installed:

#!/bin/sh
/Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh
kextunload -b com.paloaltonetworks.GlobalProtect.gplock
# Pre Catalina
rm -r /System/Library/Extensions/gplock*.kext
# Catalina
rm -r /Library/Extensions/gplock*.kext

rm /Library/Preferences/com.paloaltonetworks.GlobalProtect.plist

for USER in $(ls -ld /Users/* | grep ^d | grep -v "Shared" | awk {'print $NF'})
    do
        rm "$USER"/Library/Application Support/PaloAltoNetworks/GlobalProtect
        rm "$USER"/Library/Preferences/com.paloaltonetworks.GlobalProtect*
        rm "$USER"/Library/Preferences/PanGPS*
    done

killall cfprefsd

@jason.bracy Would you be willing to share the XML of the plist you're deploying? In limited testing, my custom Configuration Profile conflicted with settings GlobalProtect configured after initial setup.

My current approach is to use the following in our install policy, Files and Processes > Execute Command > …

/usr/libexec/PlistBuddy -c "Add :Palo Alto Networks:GlobalProtect:PanSetup:Portal string YOUR.FQDN.GOES.HERE" /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist ; /usr/bin/su - "`/usr/bin/stat -f%Su /dev/console`" -c "/usr/bin/pkill -l -U `/usr/bin/stat -f%Su /dev/console` GlobalProtect" ; /bin/sleep 3 ; /usr/local/bin/jamf recon

@dan-snelson The plist uploaded to the configuration profile is very simple, the Domain that I am using is in the Profile is: com.paloaltonetworks.GlobalProtect and then I uploaded the following XML

<?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>Portal</key> <string>xxx.xxxx.xxx</string> </dict> </plist>

-portal address scrubbed to protect my network :-)

Thanks, @jason.bracy … I had w-a-y more keys in mine.

@dan-snelson looks like you were also using the domain "com.paloaltonetworks.GlobalProtect.settings" not "com.paloaltonetworks.GlobalProtect". In my testing using that did not work. Deleting all GP settings files (previous comment) and using the Configuration Profile with the the com.paloaltonetworks.GlobalProtect domain and the single portal key has been very solid and will then create the com.paloaltonetworks.GlobalProtect.settings file with the config that it gets from the server.

defaults read com.paloaltonetworks.GlobalProtect.settings { "Palo Alto Networks" = { GlobalProtect = { PanMSAgent = { "Client.DebugLevel" = 5; PanGPS = 5; SearchOrder = 1; "Service.DebugLevel" = 5; }; Settings = { ConfFromPortal = 7212; Configurations = 154; Configurations2 = 79; DisallowLocalAccess = 0; DisplayTrafficBlockingMsg = 1; DisplayWelcome = 1; HipCheckInterval = 0; LastUrl = "xxx.xxxx.xxx"; LocalSSLEnabled = 0; OtherDisableStarted = 0; OverrideMethod = allowed; UserOverrides = 3; "agent-user-override-timeout" = 0; "mfa-prompt-suppress-time" = 0; "ssl-only-selection" = 0; }; "Settings\\xxx.xxxx.xxx" = { AuthTypes = 32; ConfFromPortal = 7212; Configurations = 154; Configurations2 = 79; DisplayTrafficBlockingMsg = 1; DisplayWelcome = 1; HipCheckInterval = 0; LocalSSLEnabled = 0; OtherDisableStarted = 0; OverrideMethod = allowed; UserOverrides = 3; "agent-user-override-timeout" = 0; "mfa-prompt-suppress-time" = 0; }; }; }; }

I've just gone through all of this. Palo Alto has changed the preference file, domain and format.

So for client version 5.0.4:

Domain: com.paloaltonetworks.GlobalProtect

<?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>Palo Alto Networks</key>
    <dict>
        <key>GlobalProtect</key>
        <dict>
            <key>PanGPS</key>
            <dict>
                <key>UserProfileType</key>
                <integer>0</integer>
            </dict>
            <key>Settings</key>
            <dict>
                <key>connect-method</key>
                <string>on-demand</string>
                <key>disable-globalprotect</key>
                <integer>1</integer>
                <key>prelogon</key>
                <integer>0</integer>
                <key>regioncode</key>
                <string>US</string>
            </dict>
        </dict>
    </dict>
    <key>PanPortalList</key>
    <array>
        <string>vpn.corp.com</string>
    </array>
</dict>
</plist>

For client version 5.1.3-12

Domain: com.paloaltonetworks.GlobalProtect.client

<?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>vpn.corp.com</string>
    </array>
    <key>User</key>
    <string></string>
</dict>
</plist>

I hope that helps. I'm deploying both right now just to cope. I really wish devs wouldn't do this.

@franton Thanks for the heads up on this. Developers should be required to do IT support for their product and see first hand how much people appreciate such major structural changes in minor version updates.

@sdagley This kind of arbitrary change from Vendor's really annoys me. It's caused no end of bother in my org.

Thanks, @franton; worked like a champ.

@franton are these profiles being deployed as custom configuration profiles in Jamf. If so, are they set at the computer level or user level? Or, are the profiles deployed manually through a package or other means?

@franton are these profiles being deployed as custom configuration profiles in Jamf. If so, are they set at the computer level or user level? Or, are the profiles deployed manually through a package or other means?

I'm also curious the best way to get this into the user's ~/Library/Preferences - I have tried "write defaults" as a script but can't get it to write it to the local user.

TIA

@captam3rica I'm deploying as computer level for everything.

When I use @franton's profile, my GP hangs at "Connecting..." indefinitely. As soon as I unscope the profile, GP prompts for the portal and can connect. This is GP 5.1.5 - upgrading from 5.0.3.

@tep had issues with that. found that one of the background processes can get stuck, but force killing them and effectively restarting the client helps. Our situation is mostly caused by our SAML based login.

@franton Do you have an example of a plist for 5.1.3-12 that also includes the

<key>connect-method</key> <string>on-demand</string>

portion? No matter what I try on that, I cannot get it to work. I know I'm missing something simple, but I'm about to tear my hair out over this... their website is absolutely no help!

@elsmith sadly I do not. If you find it, please post it here.

@franton Will do! Thank you :) I think I'm close (or maybe I just haven't had enough coffee)

@elsmith I am having the exact same problem - I was able to set the portal address using @franton s method (thank you for that) but I cannot get the connect-method setting to work no matter where I put it. using the new 5.2.2 client btw. I think I will have to get my networking team to engage with PAN support unless someone knows the secret sauce

@franton Am I imagining things, or did Palo Alto change the configuration back to the 5.0.x format for 5.2.x? (My org skipped the 5.1.x Mac releases)

@sdagley I am still having to use Franton's method for the portal address plist file for both 5.2.2 and the new 5.2.3, I am unable to get the connect-method setting to work at all still, even when I place the plist files manually in both preferences folders without using jamf . I am having our network engineers open a TAC case for me on this, I will let you know what I discover.

@dan-snelson thanks for your Files and Process Execute Command. And it's much appreciated!

@sdagley No idea. Only just started on 5.2.4 testing ... and I've still got both sets of profiles deployed.