Hello @kostas_athanas1, I believe this is what you're looking for:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HAW8

@sdagley so it sounds like you are talking about something I encountered in 5.1.7 (see screenshot). We opened a case wit PA and they came back with Apple's macOS Big Sur 11.0.1 Release Notes (not realizing the intended audience is the vendor not the end user). It states:

Security

New Features

         macOS Big Sur 11 beta improves system security by requiring an administrator password when a certificate trust settings change is made in the admin trust domain. Running as the root user alone is no longer sufficient to modify certificate trust. User trust domain settings continue to require confirmation by entering the password for the user’s account. This change may affect you if one of the following is true:

o    You have written scripts which call /usr/bin/security add-trusted-cert -d ... as root.

o    Your process runs as root and calls the SecTrustSettingsSetTrustSettings function to trust a certificate.

         Workflows that add trust settings in the admin trust domain, such as for an enterprise root certificate, may require modification if the user can’t authenticate as an administrator at the time settings are changed. (21855995)

Workaround: Use Apple Configurator 2 to create and install a configuration profile containing your root certificate.

Our ask of PA:

Proposed Solution: For PA to use Apple’s suggested workaround. One of the following solutions should suffice:

1. Provide a signed configuration profile containing 1 payload: the required root certificate
2. Provide the required root certificate to be used in our own signed configuration profile

Then they came back and said they don't provide those solutions or file types. And I then replied with their own KB where they do in-fact offer config profiles and instructions on how to create them. and then reiterated...

Palo Alto is performing an action where scripted actions that are no longer supported by Apple due to increased security. The provided workaround for the vendor is clearly stated and should be provided to their customers by one of the two methods discussed already.

Interestingly in our 5.2.8 testing, we have not seen this prompt for the system level cert. So maybe they fixed this?

@TechM I never followed up my post in this thread, but I solved the problem by extracting the PaloAltoCA certificate from a Mac that had already connected via GlobalProtect, and then added a Certificate payload with that certificate to the Configuration Profile we deploy to approve the GlobalProtect System Extension.

As for why you didn't see the cert prompt with 5.2.8, had those Macs previously connected with any other version of GP? I don't believe that cert changes between client versions, but will depend on GP host server.

@gregsheppard It's a handy guide for sure, but I don't see anything about the certificate prompt we're all getting...

@TechSpecialist Are you referring to the prompt for System Certificate Trust settings? If so, extract the PaloAltoCA certificate from a Mac that had already connected via GlobalProtect, then add it a Certificate payload in the Configuration Profile you deploy to approve the GlobalProtect System Extension.

@sdagley is correct put just add that PA cert to a configuration profile. 

Just saying thanks! This worked for me!

@Saikat thanks for sharing, how would you add the CERTIFICATESTORELOOKUP= "user and machine" key? would that be possible with this method?

Hoping to resurrect an old thread here. 😏 I can't get GlobalProtect (v. 5.2.12) to recognize my config profile that is structured like this:

Any idea what I might be doing wrong? The Managed Preference takes precedence over the ones in /Library/Preferences and ~/Library/Preferences, right?

@markopolo Trying to use a Configuration Profile to configure the portal settings for GlobalProtect is like micturating into the wind. Save yourself some frustration and use @franton 's technique posted below on ‎12-19-2020 06:26 PM for using defaults write to create the .plist into /Library/Preferences/

@markopolo 
Not sure if my experience can help but here we go!

I do recall it taking some time to figure out all the settings. I also used the GP documentation to set everything up.
In total I used 5 profiles.  I like to keep mine separate incase a change has to be made.

1. App & Custom Settings - Gateway
2. Content Filter
3. Notifications
4. Sytem Extension
5. Disk Access

I do recall our Networking team having issues with a user selecting which certificate required but they made a change an our users do not get prompt to choose a cert.

GP has been pretty stable for us.  A few quirks here and there but nothing large scale.
Here is our Gateway setting Profile.  All other settings are pushed down from GP Server once the user connects. 

The one thing that became clear to me was that Palo Alto absolutely does not care to change/fix the Mac configurations. That being said, we could never get it to work if we entered more than one portal, so we picked one and wrote a page for our users on how to add the others (we have four).

Currently, we're using the config profile for the system extensions and using the plist method that @sdagley references - works perfectly for us (still only one portal, though).

I was using a JAMF profile to configure the portal address but changed to using defaults write because issues reported by users. When using the profile, the portal was configured but users were not able to add additional portal addresses. Changing to defaults write solved this for me.

defaults write /Library/Preferences/com.paloaltonetworks.GlobalProtect.client PanPortalList -array-add portal.address.com;

Been a while since I last responded to this. Some notes:

1) Palo Alto changes the format of it's configuration files between releases. 5.1.x has a different format to 5.2.x which is different to 6.x

2) As a result, I start with the installer and a completely blank uncontrolled mac to capture what it's setting and it's formatting. That method has proved effective in helping generate config profiles for the URL settings.

3) Palo Alto provides some pre-built and signed .mobileconfig files for things like split tunnel DNS. Badger the heck out of your network team for Palo Alto documentation access. I've done a lot of this work blind and I really could have used that information.

4) That covers the URL side of things. Palo Alto still has this annoying habit of some of it's preferences won't read out from profiles but will read from the plist file directly hence the defaults write approach. That's a rabbit hole in advanced syntax I don't want to go near again.

Still all easier than a lot of other VPN clients. ;)

Much appreciated! 

Ours worked for 5.x.x but now that we are on 6.x.x - our configuration profile adds the URL but it doesnt launch the pop-up window to sign-in. 

If we try it without the configuration profile, 6.x.x works (pop-up window appears) and we would need to enter manually.

Do you happen to have Configuration Profile for 6.x.x?

Extra info:
If we use old GP 5.x.x with configuration profile, the prompt pop-up works but we would need manually update it.

# Remove GlobalProtectService keychain item from all users' login keychains.

USER_LIST=$(/usr/bin/dscl . -list /Users UniqueID | awk '$2 > 500 {print $1}')



for THIS_USER in $USER_LIST; do

    USER_HOME=$(/usr/bin/dscl . -read "/Users/$THIS_USER" NFSHomeDirectory | awk '{print $2}')

    USER_KEYCHAIN="$USER_HOME/Library/Keychains/login.keychain-db"

    if [[ -f "$USER_KEYCHAIN" ]]; then

        if /usr/bin/security find-generic-password -s "GlobalProtectService" "$USER_KEYCHAIN" &>/dev/null; then

            /usr/bin/security delete-generic-password -s "GlobalProtectService" "$USER_KEYCHAIN" &>/dev/null

        fi

    fi

done



# Fix for the GP connecting all the time instead of on demand

defaults delete /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist

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

defaults write /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist '{ "Palo Alto Networks" = { GlobalProtect = { Settings = { "connect-method" = "on-demand" }; }; }; }'

im seeing this on the 6.x client as well. My portal address is pre-configured with a config profile, machine wide, via Jamf. If I set on-demand manually before installing like your script there does everything works fine. 

 However if I set on-demand with a config profile it doesn't work, hangs up while trying to auto connect. Any ideas? 

this worked on my end. i had to kill global protect process then re-launch it.

I'm starting to test GlobalProtect 6.1.0 because I've been struggling with getting the portal address populated without a reboot. The 6.1.0 documentation references this url for configuration in Jamf Pro:

Deploy the GlobalProtect Mobile App Using Jamf Pro (paloaltonetworks.com)

I'll be testing this out this week.

This worked really well in my testing. It was clean and didn't require the user to interact with anything other than entering their username and password.

Policy for Package, Script, Inventory:

https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/mobile-endpoint-management/manage-the-globalprotect-app-using-jamf/deploy-the-globalprotect-mobile-app-using-jamf

Configuration Profile for System Extension and PPPC:

Enable System and Network Extensions on macOS endpoints Using Jamf Pro (paloaltonetworks.com)

Configuration Profile for Notifications:

No link but just used a bundle id of "com.paloaltonetworks.GlobalProtect.client"

In case you missed it, this was with the 6.1.0 package.

on version 6.1.0, deploy the application custom profile with preferences domain com.paloaltonetworks.GlobalProtect.client works.

Hello @bwoods , I think this is what you are looking for.

1. Select Content Filter from the options and configure the following values and save the configuration profile.

• FilterName = GlobalProtectEn


• Identifier = com.paloaltonetworks.GlobalProtect.client


• Socket Filter Bundle Identifier = com.paloaltonetworks.GlobalProtect.client.extension


• Socket Filter Designated Requirement = anchor apple generic and identifier "com.paloaltonetworks.GlobalProtect.client.extension" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77)


• Network Filter Bundle Identifier = com.paloaltonetworks.GlobalProtect.client.extension


• Network Filter Designated Requirement = anchor apple generic and identifier "com.paloaltonetworks.GlobalProtect.client.extension" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77)