Unable to Login on mac after deployed " GlobalProtect 5.1.3-12"

[JamfTechHelp]

Hi,

Last week we have deployed GlobalProtect 5.1.3-12 and after getting installed and restarted the mac, now when tried to login getting booting process but again come back to same login screen again and again whenever entering the password. Almost around 10 mac machines facing same issue after restarted.

Steps tried to address:

1.Reset the password from recovery mode.
2.Reset the FileVault Password from recovery mode
3.Tried to fix the user preferences settings mv /Users/username/Library/Preferences/ /Users/username/Library/Preferences/-old
chmod -R 777 /Users/username
4.Tried to Reset launch services database
find /private/var/folders | grep com.apple.LaunchServices | grep csstore
5.Removed all related folders of GlobalProtect from recovery mode and after that system getting shut down.
6.Reinstalled the macOS without formatting

Still unable to login and please suggest any troubleshooting steps to be take,

Regards,
RB

[alexjdale]

We've seen this with a very small percentage of our users, and the issue is present for them with 5.1.4 as well. We had to remove the application (using a Jamf policy since nobody could log in).

[endor-moon]

We're seeing a lot of issues with this version of GlobalProtect. Users often have difficulty clicking "Allow" to permit the kernel extension to load. I found this on the 'net that claims to solve the problem, but it involves booting into Recovery mode and issuing a Terminal command, which users may not be up for:

Restart the mac with command-r to get to Recovery mode. Open Terminal from
the Utilities menu at the top of the screen. Enter this command:

spctl kext-consent add PXPZ95SK77

Quit Terminal, restart from the Apple menu.

Then reinstall the global protect client.

Check this link for more details

https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-is-not-Connecting/ta-p/53185

[zbrooks]

Hi all, we just started experiencing this same thing on version 5.2.1-9, also for a small percentage of users as @alexjdale mentioned. Currently trying to remove through JAMF, but it doesnt seem to want to check in to pick up the policy.

@alexjdale Can you expand on how you deployed your uninstall for me?

[alexjdale]

@zbrooks We have our JSS available on or off network, so we simply deploy the uninstall policy at startup/recurring, so it will run at the login window. As long as the device can connect to a network, it'll run.

I'm assuming safe mode would work as well to run the removal script that is located inside the GP app.

[jonathandykerma]

I've seen this issue on two occasions after a GlobalProtect app update. I was able to resolve by removing the gplogin:login,privileged auth mechanism from the system.login.console authorizationdb. This allowed the user to login. Then reinstall the GlobalProtect package.

security authorizationdb read system.login.console > "/tmp/auth.plist"
sed -i -e "/gplogin:login,privileged/d" "/tmp/auth.plist"
security authorizationdb write system.login.console < "/tmp/auth.plist"

[alexjdale]

@jonathandykerman It sounds like after reinstalling, the issue did not return? We'll try this out for our next incident, thanks for the tip.

[cbd4s]

@jonathandykerman , thanks for the tip. Worked out in recovery mode the command can be run like this:
/Volumes/Macintosh HD/usr/bin/security authorizationdb read system.login.console

But sadly on a machine that we've got with this login issue, there is already no <string>gplogin:login,privileged</string>.

[cbd4s]

On a few machines in our environment that have been impacted by this mysterious problem, the frustration is that the computer also loses the ability to connect to wired network under normal startup prelogin when I can confirm the same wired network connection is active in the recovery mode. This makes deploying uninstallation through Jamf policy impossible.

Yes, we've also tried most of the things in the original post plus:
1. Safe mode boot
2. Single user boot (still requires user login so the problem still happening)
3. Remove .AppleSetupDone file to create new account (stuck at language selection step)
4. Rename the entire user profile folder
5. In the recovery mode, manually run uninstall shell script commands that's part of the GlobalProtect.app contents
6. Replace the /private/var/db/launch.db/com.apple.launchd/overrides.plist file from a working machine
7. Move all kernel extensions under /Library/Extensions to a temporary folder to stop them from running
8. Remove all the non apple plists in /Library/LaunchAgents and LaunchDaemons

Unfortunately, none of these fixes the problem.

[jason_bracy]

Seems like this is very similar to what we have been experiencing deploying GP 5.1.6. I ended up reverting back to 5.0.8 which seems to work fine:
1) Boot in Safe Mode
2) Login as local admin
3) (optional) Load JAMF Frameworks: Open Terminal and run:

sudo launchctl load -w /Library/LaunchAgents/com.jamfsoftware.jamf.agent.plist
sudo launchctl load -w /Library/LaunchDaemons/com.jamf*

4) Uninstall all GP 5.1.x by running the following script or via Self Service Item (I have this script scoped to our Admin Users available in Self Service)

#!/bin/sh

/Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh
kextunload -b com.paloaltonetworks.GlobalProtect.gplock
rm -r /System/Library/Extensions/gplock*.kext
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/Preferences/com.paloaltonetworks.GlobalProtect*
    done

killall cfprefsd

4) Reinstall GP working version manually or via another Self Service Policy.

Will be testing 5.1.7 over the holiday as we don't have approval to move to the 5.2.x branch yet.

[cbd4s]

@jason.bracy unfortunately, the login problem also happens with safe boot

[jason_bracy]

@cbd4s when in safe boot you need to login as a local admin.

[cbd4s]

Sorry, @jason.bracy , that is exactly the problem, even under safe boot, we can't log in as anyone including local admin which makes running any of those commands and uninstallation not possible.

[Gonzalez]

@cbds If you run a policy at checkin scoped to the computers impacted that runs the script Jason posted; it should uninstall GP with out the need to log on. This happened to us when we forced an upgrade, for the handful of systems in this state is just waited for the policy to run.

[cbd4s]

Thanks for the reply, @Gonzalez. Yes, but check-in / policy execution / ssh access is only possible if the machine can connect to Jamf server. Unfortunately, for the few machines in our environment, they were not able to connect to any network wired or wireless. So the only access to these machines are physically through recovery mode or target disk mode.

[jason_bracy]

OK, if you can't even login as a local user (which seems odd but...) you can boot to Recovery Mode, Launch terminal from the Utilities and run the following:

chroot /Volumes/Macintosh HD/
/Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh
rm -r /System/Library/Extensions/gplock*.kext
rm -r /Library/Extensions/gplock*.kext
rm /Library/Preferences/com.paloaltonetworks.GlobalProtect.plist