babgond

The documentation from MacSysAdmin 2024 is available, with the session slides and videos being accessible from the link below:

http://documentation.macsysadmin.se

The video of my session is available for download from here:

macOS Application Packaging 101: https://docs.macsysadmin.se/2024/video/Day1Session6.mp4

I also like to thank Patrik Jerneheim again for inviting me to speak at this year’s MacSysAdmin.

For those who wanted a copy of my installer packaging talk at the MacSysAdmin 2024 conference, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/MSA2024PDF
• Keynote: https://tinyurl.com/MSA2024Keynote

At the end of July, I made the following announcement via Twitter:

https://x.com/rtrouton/status/1815414758184558984

Time has marched on and today is my last day at SAP. I wanted to take the opportunity to express my gratitude to my team. I am proud of what we were able to do together and wish each one of you every success for the future.

One of the things that I valued greatly while I was at SAP was that I was encouraged to write (both for this blog and my first book), speak at conferences and be involved with the Mac admin community. Thank you to everyone at SAP who provided this encouragement and made sure I always had what I needed.

I look forward to continuing to speak, write and be engaged with community work as part of my move to Jamf, where I’m joining a great team doing amazing things for Jamf’s customers. May the next seven years be as good (or better!) as the past seven.

A while back, I needed to update Macs with asset tag numbers with information from a .csv file, where the .csv file contained the following information:

• The Mac’s hardware serial number
• Asset tag number

To handle this task, I wrote a script which uses the Jamf Pro Classic API to look up the relevant computer inventory record in Jamf Pro using the Mac’s serial number and then update the computer inventory record with the matching asset tag number. For more details, please see below the jump.

This script reads a .csv file formatted as follows:

Serial number, Asset number as the first line

Subsequent lines:

• Column 1: A Mac’s hardware serial number
• Column 2: An inventory asset code

Example file:

This script is designed to run as shown below:

/path/to/Jamf_Pro_Inventory_Asset_Tag_Update.sh filename_goes_here.csv

Once executed, the script will then do the following:

1. Skip the first line of the .csv file (this is the Serial number, Asset number line.)
2. Read each subsequent line of the .csv one at a time and assign the values of column 1 and column 2 to separate variables.
3. Use the variables in an API PUT call to identify a Jamf Pro computer inventory record using the Mac hardware serial number listed in the .csv file and populate the asset tag information using the inventory asset code listed in the .csv file.

Successful update of the asset tag information should produce output similar to that shown below:

If setting up a specific user account with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects:

Computers: Read, Update

The script is available below, and from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Inventory_Asset_Tag_Update

Now that the spctl tool can no longer separately manage Gatekeeper, management profiles are the best way to manage Gatekeeper on macOS Sequoia. For more details, please see below the jump.

On macOS Sequoia, the following management options are available (all use boolean values of true and false):

AllowIdentifiedDevelopers

• If set to true, this setting enables Gatekeeper’s Mac App Store and identified developers option.
• If set to false, this setting enables Gatekeeper’s Mac App Store option, which restricts Gatekeeper to only accepting apps from Apple’s Mac App Store.

EnableAssessment

• If set to true, this setting enables Gatekeeper to assess applications. This works in combination with the AllowIdentifiedDevelopers setting described above.
• If set to false, this setting sets Gatekeeper to accept all apps (effectively disabling Gatekeeper.)

Please see below for example profiles:

Disable Gatekeeper:

Enable Gatekeeper and allow Identified Developers:

Enable Gatekeeper and not allow Identified Developers:

Both of these management options (AllowIdentifiedDevelopers and EnableAssessment) have been around for a while, but there is a new management option for macOS Sequoia. On Sequoia, Gatekeeper can now prompt the user to upload blocked malware to Apple for Apple to analyze. As part of this, Apple added the following management option:

EnableXProtectMalwareUpload

• If set to true, this setting enables Gatekeeper to prompt the user to upload blocked malware to Apple.
• If set to false, this setting prevents Gatekeeper from prompting the user to upload blocked malware to Apple.

Please see below for example profiles:

Allow XProtect Malware Upload:

Block XProtect Malware Upload:

On macOS Sonoma and earlier versions of macOS, the spctl command line tool could be used to turn Gatekeeper on and off. For example, on macOS Sonoma the following command can be run with root privileges to disable Gatekeeper:

After running this command, in System Settings: Privacy and Security, you should see Gatekeeper displaying that it is set to Anywhere:

Also on macOS Sonoma, the following command can be run with root privileges to enable Gatekeeper:

After running this command, in System Settings: Privacy and Security, you should see Gatekeeper displaying that it is set to App Store and identified developers:

On macOS Sequoia, this Gatekeeper management approach no longer works. For more details, please see below the jump.

On macOS Sequoia, running the command to disable Gatekeeper produces the following output:

Globally disabling the assessment system needs to be confirmed in System Settings.

On macOS Sequoia, running the command to enable Gatekeeper produces the following output:

This operation is no longer supported. Please see the man page for more information.

In both cases, the Gatekeeper settings in System Settings: Privacy and Security should remain unchanged.

One of the changes made as part of macOS Sequoia is that the location of Keychain Access.app has moved:

In macOS Sonoma and earlier, Keychain Access.app is in the following location:

/Applications/Utilities/Keychain Access.app

As of macOS Sequoia, Keychain Access.app is in the following location:

/System/Library/CoreServices/Applications/Keychain Access.app

Since the introduction of system extensions in macOS Catalina, Apple has been adding controls for both individual users and Mac admins to allow management of system extensions. For individual users who manage their own Macs without using MDM management, Apple asks the user to approve the system extensions functions. In turn, for managed environments, Apple has provided management profile options to allow Mac admins to pre-approve or block system extensions from running on the Macs in that environment.

As part of the release of macOS Sequoia, Apple has added new user functionality for managing system extensions, as well as management profile options for Mac admins. For more details, please see below the jump.

The new functionality is the ability to manage installed system extensions via System Settings, with the relevant controls being found in System Settings: General: Login Items & Extensions. As an example, let’s look at the LuLu open-source firewall app. This app uses a network extension and a content filter.

On macOS Sonoma, the following management profiles can be deployed to allow LuLu’s network extension to be deployed and removed without the user being prompted.

Profile to allow deployment and removal:

Profile to configure the content filter:

On macOS Sequoia, the new functionality referenced earlier is not managed by either profile. Instead, if you look at System Settings: General: Login Items & Extensions, you should see a Network Extensions entry in the Extensions section.

When you click on the (i) option for the Network Extensions entry, you should see controls like what’s shown below. These controls include the ability to disable the system extension.

To manage this new functionality, Apple has added a new NonRemovableFromUISystemExtensions key to the existing com.apple.system-extension-policy payload for managing system extensions. The following management profile can be deployed to macOS Sequoia Macs to prevent the user from being able to disable the LuLu network extension.

Once deployed, the user controls available via the Network Extensions entry will be grayed out and the user will not be able to change those settings.

Note: Something to be aware of is that the NonRemovableFromUISystemExtensions key only works on macOS Sequoia and older versions of macOS, including macOS Sonoma, will ignore it. This means that deploying profiles which use this NonRemovableFromUISystemExtensions key to older versions of macOS will not result in the new management settings being applied to macOS Sequoia when the Mac is upgraded to run macOS Sequoia. Instead, profiles which use this NonRemovableFromUISystemExtensions key should only be deployed to macOS Sequoia as of this time.

One of the functions that Apple’s mobile device management (MDM) has had for years is the ability to send a remote lock command. In this case, an MDM command is sent to a device and a passcode is required in order to clear the lock.

However, sometimes this passcode can get mislaid or forgotten due to insufficient record keeping. In this case, how to clear the lock when you don’t have the passcode? On Apple Silicon Macs, it’s possible to clear the lock but it will require all data on the Mac to be destroyed and the operating system to be reloaded from scratch.

For more details, please see below the jump.

The solution is to put the Apple Silicon Mac into DFU mode and use Apple Configurator running on another Mac to restore the Mac using an IPSW file for the desired operating system. Apple has a KBase article describing how to perform this restoration process available via the link below (follow the Restore procedures):

• How to revive or restore Mac firmware: https://support.apple.com/108900

Once the Mac has been restored, the lock should be cleared and a factory-fresh copy of macOS should be installed.

In the event that this process does not work, the other option available is a logic board hardware repair where the Mac’s existing logic board is exchanged for a new replacement one.

A while back, I had written a post about using custom variables in an AutoPkg recipe to set version information. Part of my earlier post references using the EndOfCheckPhase processor as a safe way to set variables because the EndOfCheckPhase processor takes no actions. However, even the EndOfCheckPhase processor isn’t completely safe because it does do something even if the processor itself takes no actions and natively sets no output variables. This is because AutoPkg uses it to figure out if it should stop checking for new information as part of a recipe’s run.

To provide a completely safe way to set custom variables in an AutoPkg recipe, I decided to write a VariablePlaceholder AutoPkg processor which truly does absolutely nothing except serve as a convenient way to set custom variables. For more details, please see below the jump.

The VariablePlaceholder processor takes no actions and does nothing. It’s usefulness comes from the fact that AutoPkg will still process Arguments values if they’re defined for the VariablePlaceholder processor. The workflow in this case looks like this:

1. Add the VariablePlaceholder processor where needed in the AutoPkg recipe.
2. Perform the desired variable assignment as an Arguments value.

For example, if you need to set the version output variable in an AutoPkg recipe by combining two other output variables (in this example, a major_version variable and a minor_version variable), the VariablePlaceholder processor can be used to do this in a safe way.

A recipe which uses this example setup is shown below:

The VariablePlaceholder processor is shown below, as well as being available via the following link:

https://github.com/rtrouton/AutoPkg_Processors/tree/main/VariablePlaceholder

If you want to use the VariablePlaceholder processor hosted from my AutoPkg recipe repo, first verify that AutoPkg is installed on the Mac you’re using. Once verified, run the following command: