bvanpeski / unactivationlock

A tool for ensuring user-based activation lock remains off.

Hi there 👋

I currently work as a solutions engineer at a SaaS company after almost a decade of doing IT / Apple Device Management.

🧑🏽‍💻 You may recognize me from such projects as:

• SystemPreferences - Catalog of all macOS System Settings interfaces that you can interact with via script.
• UnActivationLock - A zsh script that detects if a device is activation locked and prompts the user to log out of FindMy so that your MDM can lay down an activation lock bypass.
• ScreenNudge - A zsh script designed to prompt the end-user to approve screen recording for a given app BEFORE they need it or launch it for the first time.

📫 How to reach me:

• You can read my blog at https://macosadventures.com
• I'm @brianvp on the MacAdmins Slack

unactivationlock's Issues

System Settings doesn't auto launch on 14.2.1

At some point beyond 14.2, System Settings stopped auto launching to the iCloud pane (or any other pane for that matter).

I wiped a test device to 14.2, and things worked as expected. Upgraded to 14.2.1 and things continued to work as expected.

Ventura Command for System Setting

I spent a ton of time beating my head against this same issue while building my own version of this project. The command to get you to where you need to be in Ventura is

open "x-apple.systempreferences:com.apple.preferences.AppleIDPrefPane?iCloud"

Awesome project!

Two Possible Issues for some situations

I'm not confident enough in my coding ability to submit changes, but there are two situations you might want to account for...

1. Machines that aren't running 13.x - I added this to my version...

SWtest=$(sw_vers | grep ProductVersion | awk '{print$2}' | cut -c 1-2)
if [[ "$SWtest" -lt "13" ]];then
SysPref="System Preferences"
else
SysPref="System Settings"
fi
...and then changed each instance of "System Settings" to "'"$SysPref"'"' to open the correct one.

2. I actually did have one machine that came back with no users with a FindMy token associated. I didn't have time to troubleshoot, but the current logged in user WAS the one with their AppleID signed in and FindMy enabled. And wee have several machines with a generic login (i.e. "editor") and for some reason the fools enabled their AppleID. (facepalm).

So I'm working to add one dialog subroutine that'll alert the signed in user to see if they can disable Find My if 'no user' was reported, and another sub-routine to say what AppleID is being used and to warn the signed in user if they're that user to sign out of that AppleID account (or at least disable Find My).

Script is missing that Find My is turned on

I ran the script on a device where I had Find My turned on for testing purposes, but it seems it's not picking this up.
The response is empty and says that the activation lock is disabled. This device is on Sonoma 14.3.1.
Any idea why it would be return this as such?
Thank you.

added email address

No issue but I don't know how GitHub works! :) Added this to help user understand what email is logged in (not obvious for everyone).

##############################################################

USER INPUT

##############################################################
currentUser=$(ls -la /dev/console | awk '{print $3}')
iclouduseraccount=$(/usr/libexec/PlistBuddy -c print /Users/${currentUser}/Library/Preferences/MobileMeAccounts.plist | grep "Email" | awk 'FNR == 2 {print $3}')

Great script.

Something is wonky... - can happen

elif [[ $activationLock == "Enabled" && -z $FindMyUser ]]; then
      LOGGING "Activation lock status is $activationLock, and there are no users with a FindMy token associated. Something is wonky..."
      #I don't think this can happen, but leaving it here just in case.

Source

Can confirm, this can happen. :)

Script result: Activation Lock Status: Enabled | ADE-Enrolled: Yes
--- User-Based Activation Lock is: Enabled. Checking local users...
--- Checking Activation Lock status for the following users: first.last Jamfadmin...
Activation lock status is Enabled, and there are no users with a FindMy token associated. Something is wonky...

Username changed to first.last

I can confirm that the device does have Find My enabled, based on the output of:
fmmToken=$(/usr/sbin/nvram -x -p | /usr/bin/grep "fmm-mobileme-token-FMM")

But according to the output of:
/usr/libexec/PlistBuddy -c print "/Users/first.last/Library/Preferences/MobileMeAccounts.plist"

          apsEnv = production
          url = https://p52-fmip.icloud.com:443
          pairingURL = https://gateway.icloud.com/fmadminws
          authMechanism = token
          hostname = p52-fmip.icloud.com
          appHostname = p52-fmipmobile.icloud.com
          Name = FIND_MY_MAC
          Enabled = false
          ServiceID = com.apple.Dataclass.DeviceLocator
        }

This file does not exist for Jamfadmin.

Under System Settings > iCloud, Find My Mac is turned on.

Find My status is set to True despite not being enabled/no iCloud account signed in

I've got this set up on some devices for testing and just tried it on a device that does NOT have an iCloud account signed in. This was the result:

I'm finding that /usr/sbin/nvram -x -p | /usr/bin/grep "fmm-mobileme-token-FMM" seems to be much more accurate at determining the Find My status and have created an extension attribute that checks this.

Whilst this is mentioned in your README why you don't use it, I think it could still be useful to implement into your script to at least have better Find My status detection (in addition to great activation lock detection).

This is the EA I use for Find My detection in Jamf:

#!/bin/bash

fmmToken=$(/usr/sbin/nvram -x -p | /usr/bin/grep "fmm-mobileme-token-FMM")

if [ -z "$fmmToken" ]; then
	echo "<result>FindMy is Disabled</result>"
else
	echo "<result>FindMy is Enabled</result>"
fi

exit 0