A while ago, I wrote a post on how to back up your Jamf Pro Self Service bookmarks. I’ve been using that process to back up my bookmarks and it’s been working fine until after my upgrade to Jamf Pro 10.30.0. At that point, my script stopped working. When I checked into it and talked with some colleagues, it became apparent that Jamf had made a change with how they stored bookmark information for Self Service.

In 10.29.x and earlier, Jamf had stored bookmarks as individual plist files in the following location:

/Library/Application Support/JAMF/Self Service/Managed Plug-ins

In 10.30.x and later, the /Library/Application Support/JAMF/Self Service/Managed Plug-ins directory has disappeared.

Jamf now stores bookmark information inside an XML file named CocoaAppCD.storedata in the user’s home folder at the following location:

~/Library/Application Support/com.jamfsoftware.selfservice.mac/CocoaAppCD.storedata

Inside the CocoaAppCD.storedata file, the bookmarks are stored as XML objects similar to what is shown below:

Fortunately, I was able to figure out a way to do the following:

1. Parse the document for the bookmark XML objects.
2. Split them out into individual XML files.
3. Name the files using the title of the Self Service bookmark.

For more details, please see below the jump.

To make backups of the Self Service bookmarks, I’ve written a script which performs the following tasks:

1. If necessary, create a directory for storing backup copies of the Self Service bookmark files.
2. Make copies of the Self Service bookmark files.
3. Name the copied files using the title of the Self Service bookmark.
4. Store the copied bookmarks in the specified directory.

Once the script is run, you should see copies of the Self Service bookmark files appearing in the script-specified location. This location can be manually set or created automatically by the script.

When examined, the files should look similar to this:

The script is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Self_Service_Bookmark_Backup

Jamf_Pro_Self_Service_Bookmark_Backup.sh:

To help maintain the security of the Apple Silicon Macs in your environment, it’s helpful to be able to monitor what the Startup Security settings are for those Macs.

For this task, the reporting functions of the bputil tool are available. Normally, Apple wants you to avoid the bputil tool like you would a swarm of bees. As part of that, the following warning is displayed by bputil:

However, the bputil -d command is safe to use as it displays the contents of the current security policy’s settings. When the default Full Security security mode is enabled, running the bputil -d command with root privileges should display content similar to what’s shown below:

Here’s what bputil -d will return if the Startup Security settings are configured as follows:

• Reduced Security: Enabled
• Allow user management or kernel extensions from identified developers: Enabled
• Allow remote management of kernel extensions from identified developers: Enabled

Note: This reporting function does not require macOS Recovery and works while booted from regular macOS.

To check the Startup Security settings, the following status codes should be checked:

• smb0
• smb2
• smb3

In the Startup Security Utility app in macOS Recovery, the following settings correspond to the status codes listed above:

• smb0: Full Security / Reduced Security
• smb2: Allow user management of kernel extensions from identified developers
• smb3: Allow remote management of kernel extensions from identified developers

For more details, please see below the jump.

If you want to check to see if an Apple Silicon Mac is set for Full Security or Reduced Security, run the command shown below with root privileges:

If Full Security is set, you should see the following result:

absent

If Reduced Security is set, you should see the following result:

1

If you want to check to see if an Apple Silicon Mac is set for Allow user management or kernel extensions from identified developers, run the command shown below with root privileges:

If Allow user management or kernel extensions from identified developers is not set, you should see the following result:

absent

If Allow user management or kernel extensions from identified developers is set, you should see the following result:

1

Note: If this setting is returning a value of 1, this means that Reduced Security is enabled, so the smb0 status code will also return 1.

If you want to check to see if an Apple Silicon Mac is set for Allow remote management of kernel extensions from identified developers, run the command shown below with root privileges:

If Allow remote management of kernel extensions from identified developers is not set, you should see the following result:

absent

If Allow remote management of kernel extensions from identified developers is set, you should see the following result:

1

Note: If this setting is returning a value of 1, this means that Reduced Security is enabled, so the smb0 status code will also return 1.

One of the recent changes for the macOS version of SAP GUI for Java is that both SapMachine Java 11 and OpenJFX 11 are now bundled with SAP GUI, so it is no longer required to have Java installed on your machine in order for SAP GUI to work. This change has also been extended to the SAP GUI installer, which is now available as a notarized installer application as of SAP GUI 7.70.

You can run this installer on a Mac which does not have Java already installed and it will install SAP GUI for Java with SapMachine Java 11 and OpenJFX 11 installations embedded inside the SAP GUI application.

Note: As of SAP GUI 7.70 rev 2, Rosetta 2 is required if installing on an Apple Silicon Mac so Rosetta needs to be installed and running before installing SAP GUI.

The installer application is available for download to customers via a link on the announcement blog post:

https://blogs.sap.com/2021/03/16/ann-sap-gui-for-java-7.70-available-for-download/

When you click the download link, you will see two choices:

• DMG
• JAR

The DMG download will provide the notarized installer application and the JAR download will provide the Java .jar installer that SAP GUI has traditionally used on macOS. I’ve discussed how to package the .jar installer in previous posts, so this post is going to focus on the new installer application contained inside the DMG download.

For more details, please see below the jump.

If you want to run the SAP GUI installer application without repackaging it as a macOS installer package, use the procedure below:

1. Download the disk image.

2. Mount the disk image.

3. Copy the SAP GUI for Java Installer application to a convenient location.

If you have a templates.jar file, copy the templates.jar file to the same location. As long as both files are in the same directory, the SAP GUI for Java Installer application will detect and use the templates.jar file’s contents to help configure SAP GUI.

4. Launch the SAP GUI for Java Installer application.

5. Follow the prompts to install.

To build an installer package for SAP GUI which uses the installer application, use the procedure shown below:

Building the SAP GUI installer

Pre-requisites:

• Packages
• SAP GUI for Java Installer application
• templates.jar file (optional)

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project SAP GUI 7.70 rev2.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

• Identifier: set as appropriate (for my installer, I’m using com.sap.pkg.SAPGUI770rev2
• Version: set as appropriate (for my installer, I’m usings 7.70.02 )

In the Post-installation Behavior section:

• On Success: should be set to Do Nothing

In the Options section:

• Require admin password for installation should be checked
• Relocatable should be unchecked
• Overwrite directory permissions should be unchecked
• Follow symbolic links should be unchecked

7. Select the Payload tab. Nothing here should be changed from the defaults.

8. Select the Scripts tab.

Under the Additional Resources section, add the following files:

• The latest SAP GUI for Java installer (this is the SAP GUI for Java Installer application file)

• If you have a templates.jar file, also add that file.

The last part is telling the SAP GUI for Java installer to run. For this, you’ll need a postinstall script.

Here’s the postinstall script being used for this installer package:

If not already selected, select the postinstall script and add it to the project.

9. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Does not have the SAP GUI client installed

The end result should be that the SAP GUI client installs into /Applications.

If a templates.jar file was included with the installer, the SAP GUI configuration files specified by the templates.jar file should also be installed.

For those that need to sign their AutoPkg-generated installer packages with a signing certificate, the PkgSigner processor is available to assist with this. When I originally started using this processor, I was building the signing part directly into .pkg recipes, but my teammate @jaharmi came up with a better and more modular idea: the .sign recipe.

The .sign recipe uses the PkgSigner processor and is designed to be placed in the AutoPkg workflow between a .pkg recipe and a.jss recipe for JSSImporter, a .munki recipe for Munki or other recipes used to upload an installer package to a deployment tool. In this case, the .pkg recipe would be a parent recipe for the .sign recipe. In turn, the .sign recipe would be used as the parent recipe for whatever came next in the workflow.

For those who want to use .sign recipes, there is an example recipe available via the link below:

https://github.com/autopkg/rtrouton-recipes/blob/master/SharedProcessors/Example.sign.recipe

If you want to use the PkgSigner 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:

autopkg repo-add rtrouton-recipes

Every so often, you may find yourself in a situation where you need to reinstall macOS Big Sur and everything is failing on you. Installing from macOS Recovery? Not working via the usual methods. Building a USB installer? Left the flash drive in your other pants. Using DFU mode and Apple Configurator on an Apple Silicon Mac? You need a second Mac to use this process and you just have the one Mac available.

For those situations, there’s one more option when you’ve exhausted all of the others. For more details, please see below the jump.

This method is referenced in the following Apple KBase article:

https://support.apple.com/HT211983

It involves the following:

• Wiping the drive that you intend to install macOS Big Sur onto.
• Creating the proper directory structure manually on the drive.
• Copying the Install macOS app available in macOS Recovery manually into the proper location on the drive 
• Using the curl tool to download the needed installer files onto the drive
• Launching the Install macOS app
• Using the Install macOS app to install macOS Big Sur

To install macOS Big Sur using the methods described above, use the procedure below:

1. Boot to macOS Recovery.

2. Erase your Mac’s startup drive using the correct procedure for your Mac model:

Macs with Intel processors: https://support.apple.com/HT208496
Apple Silicon Macs: https://support.apple.com/kb/HT212030

By default, an erased drive is named Untitled. We’ll be using that drive name for the examples shown in this post.

2. Once the drive is erased, open Safari and go to the following URL:

https://support.apple.com/HT211983

3. Scroll to the bottom of the KBase article and locate the Or use Terminal to reinstall section.

4. Copy the complete command which begins with curl. (This will save a lot of typing later.)

5. Quit Safari.

6. Open Terminal.

7. Run the following command to change to using the drive named Untitled:

cd "/Volumes/Untitled"

8. Run the following command to create a directory named private on the Untitled drive as well as a sub-directory inside of private which is named tmp:

mkdir -p private/tmp

9. Run the following command to copy the Install macOS Big Sur.app application from macOS Recovery to the /Volumes/Untitled/private/tmp directory.

cp -R "/Install macOS Big Sur.app" private/tmp

10. Run the following command to change to the /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory:

cd "private/tmp/Install macOS Big Sur.app"

11. Run the following command to create a directory named Contents on the Untitled drive as well as a sub-directory inside of Contents which is named SharedSupport:

mkdir Contents/SharedSupport

12. Paste the copied curl command and hit the enter key on your keyboard to have the macOS Big Sur installer files be downloaded into a file named SharedSupport.dmg. The SharedSupport.dmg will be located in /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory/Contents/SharedSupport.

curl -L -o Contents/SharedSupport/SharedSupport.dmg https://swcdn.apple.com/content/downloads/01/60/071-72781-A_CZ1D1FENMH/a09fvud3xxgih7qyau9a7lhtspho36mp0l/InstallAssistant.pkg

13. Once curl has finished downloading /Volumes/Untitled/private/tmp/Install macOS Big Sur.app directory/Contents/SharedSupport/SharedSupport.dmg, run the following command to launch the macOS Big Sur installer.

./Contents/MacOS/InstallAssistant_springboard

14. Follow the prompts to install macOS Big Sur.

A number of folks noticed that certain older applications they use on macOS stopped working as of August 24th, 2021. As of this date, this appears to affect the following applications among others:

• RSA SecurID Software Token 4.2.1
• Citrix Receiver
• Cisco AnyConnect 4.7 and earlier

Note: This list is not complete, it’s just the ones I’m aware of as of August 24, 2021.

Why this is happening goes back to an episode in 2018, where Symantec had to get out of the PKI certificate issuing business because of a number of issues discovered with how Symantec had been issuing certificates.

As part of these issues, Apple issued an advisory that a number of Symantec Certificate Authority (CA) root certificates were to be distrusted by Apple on a timeline which concluded with the full distrust of Symantec CAs on February 25, 2020.

While this primarily affected website operators, Symantec also issued certificates from the affected Symantec CAs which were used to provide code signing for applications. An example of this is RSA SecurID Software Token 4.2.1.

Update 8-26-2021: RSA has released RSA SecurID Software Token 4.2.2 to resolve the issue with RSA SecurID Software Token 4.2.1. For more details, please see the link below:

https://community.rsa.com/t5/securid-access-product/updated-securid-announces-securid-software-token-4-2-2-for-macos/ta-p/640000?emcs_t=S2h8ZW1haWx8Ym9hcmRfc3Vic2NyaXB0aW9ufEtTUTg5SktCWUQxS1JHfDY0MDAwMHxTVUJTQ1JJUFRJT05TfGhL

In the case of SecureID, this app relies on Qt Core for user interface support and ships copies of the QT Core framework along with the SecureID app. SecurID stores this in the following location:

/Library/Frameworks/stauto32.framework

If you take a look at the installer, you can see where the files are supposed to go.

However, the actual file which is causing the issue is buried further down in the following location:

/Library/Frameworks/stauto32.framework/Versions/4/QtCore.cire

This file is important because the QT Core framework is shipped without Apple’s code signing, which is to say that QT is not using an Apple Developer ID signing certificate to sign QT Core. Instead, QT ships a code signing certificate chain and that information is stored in the QtCore.cire file.

One of the certificates in the code signing certificate chain is using VeriSign Class 3 Public Primary Certification Authority – G5 as its root certificate authority (root CA). That root CA is one of the Symantec CAs which is no longer trusted by Apple.

To summarize: the SecureID app has a component which is signed by a not-trusted certificate. This is causing SecureID to not trust that component, which then prevents the app from launching correctly.

Why is this happening now?

Apple released updates on August 23, 2021 for both XProtect (now version 2150) and Malware Removal Tool (now version 1.82). My assumption is that XProtect’s update included instructions to no longer accept code signing from the distrusted Symantec CAs. XProtect checks executable code on launch, so it would be working with Gatekeeper to detect and block the no-longer-trusted code signing.

What should you do?

See if your vendor has released an updated version of the app which is having problems. If they haven’t yet, I recommend contacting them to make sure they’re aware of the problem.

Hat tip to all the folks working on this issue in the MacAdmins Slack for helping diagnose the issue and why it is happening.

Every so often, it may be necessary to generate a report from Jamf Pro on which computers are assigned to a particular person. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the computer inventory records and generate a report in .tsv format.

For more details, please see below the jump.

Pre-requisites:

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

Jamf Pro Server Objects

• Computers: Read

Computer inventory records

• In Jamf Pro, the username field must be populated in the User and Location section of the computer inventory record.

For authentication, the script can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

This script imports a list of usernames from a plaintext file and uses that information to generate a report about the computers assigned to that username.

Usage:

./Generate_Assigned_Mac_Report_From_Jamf_Pro_Usernames.sh usernames.txt

Plaintext file format should look like this:

The script can also accept one username as input, if a plaintext file containing usernames
is not available.

Usage:

./Generate_Assigned_Mac_Report_From_Jamf_Pro_Usernames.sh

Once the username(s) are read from in from the plaintext file or from manual input, the script takes the following actions:

1. Uses the Jamf Pro API to download all information about the matching computer inventory record in XML format.
2. Pulls the following information out of the inventory entry:

• Jamf Pro ID
• Assigned user’s username
• Assigned user’s email
• Manufacturer
• Model
• Serial Number
• Hardware UDID

3. Create a report in tab-separated value (.tsv) format which contains the following information about the deleted Macs

• Jamf Pro ID
• Assigned user’s username
• Assigned user’s email
• Manufacturer
• Model
• Serial Number
• Hardware UDID
• Jamf Pro URL for the computer inventory record

This script will generate a report in .tsv format with information similar to what’s shown below:

One user:

Multiple users:

This script is available below and also from GitHub at the following location:

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

When setting up software for deployment, it’s usually a good idea to first send it out to a small percentage of the Macs in your environment. That way, if there’s a problem that wasn’t caught in testing, the amount of cleanup required is also small. If that initial deployment works, the software can then be sent out to greater percentages of the Mac population until all of them are eventually covered by the deployment.

This can be a pain to track manually though. New Macs come in, older ones are retired and keeping all Macs covered can turn into a significant investment of time. Fortunately, this is a task which can be automated and enable the Macs to assign themselves to deployment groups based on their machine UUID identifier. For more details, please see below the jump.

This method uses a Jamf Pro Extension Attribute, which is designed to calculate and set a numerical identifier for individual Macs based on the Mac’s machine UUID. This numerical identifier in turn is designed to be used to determine deployment groups.

Once identified, the value will be written to a plist file located in /Library/Preferences. By default, this file is named as follows:

/Library/Preferences/com.companyname.deploymentgroup.plist

You can change the companyname part by setting a different value for the organizationName variable in the Extension Attribute.

If the plist file is present in /Library/Preferences, the Extension Attribute will read the correct value from the plist file.

If the plist file is not present in /Library/Preferences, the Extension Attribute will calculate the correct value and store in the plist as the value of the deploymentGroupAssignmentValue key.

By default, this Extension Attribute is designed to assign Macs to seven deployment groups, with the following percentage of Macs assigned to each group.

When all is working correctly, the Extension Attribute will display one of the following values for each Mac:

When not working properly, the Extension Attribute will display the following value:

The Extension Attribute’s values can then be used as Jamf Pro smart group criteria to create smart groups for software deployment.

This script is available below and also from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Extension_Attributes/set_deployment_group

As part of developing new AutoPkg recipes to support SapMachine‘s new Long Term Support (LTS) distribution for Java 17, I ran into a curious problem when testing. When I ran the SapMachine Java 17 LTS installer that was being generated by AutoPkg, I was seeing the following behavior:

• SapMachine Java 17 LTS is installed by itself – no problem
• SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed – no problem
• SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed – SapMachine Java 11 LTS is removed, only SapMachine Java 17 LTS is installed now.

I double-checked the preinstall script for the SapMachine Java 17 LTS installer. It is supposed to remove an existing SapMachine Java 17 LTS installation with the same version info, but it should not have also been removing SapMachine Java 11 LTS. After a re-review of the script and additional testing, I was able to rule out the script as the problem. But what was causing this behavior? Also, why was it happening in this order?

• SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed

But not this order?

• SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed

The answer was in how the package’s package identifier was set up. For more details, please see below the jump.

When I was writing the AutoPkg .pkg recipes for SapMachine Java 17 LTS, I used the existing SapMachine Java 11 LTS .pkg recipe as a template. Included with that recipe was the following:

For AutoPkg’s PkgCreator processor, this defines the package identifier.

I didn’t change that. That was a mistake, because that meant that Apple’s Installer was going to see SapMachine Java 17 LTS as an upgrade install for an existing SapMachine Java 11 LTS installation. Why is this important?

When macOS’s Installer does an upgrade install, it does the following:

1. Consults its store of existing installer package receipts.
2. Identifies if it has a receipt by a previous installer with a matching package identifier. If multiple receipts are found, the latest installed is used.
3. Uses the Bill of Materials (BOM) stored with the receipt to generate a list of files which are in the receipt’s BOM and are not part of the new installer’s BOM.
4. Removes the files in question.
5. Adds the files from the current installer.

Note: Files added, removed or changed outside of the main installation process will not be included in the BOM. Since these files are not included in the BOM’s listing, the installer process will not move, change or delete these files. Examples of files not included or tracked by the BOM would be files added or moved by an installer package’s preinstall or postinstall scripts.

From Installer‘s point of view, the two packages were identified this way:

SapMachine Java 11 LTS

• Identifier: net.java.openjdk.sapmachine
• Version: 11.xx.xx

SapMachine Java 17 LTS

• Identifier: net.java.openjdk.sapmachine
• Version: 17.xx.xx

That meant that, on a Mac where SapMachine Java 11 LTS had been installed previously using an installer package with the net.java.openjdk.sapmachine package identifier, Installer interpreted the SapMachine Java 17 LTS install as being an upgrade for SapMachine Java 11 LTS.

In those conditions, Installer performs the following actions:

1. Consults the existing installer package receipts.
2. Identifies the latest version of the SapMachine Java 11 LTS receipt with a matching net.java.openjdk.sapmachine package identifier.
3. Generates a list of the files installed by the SapMachine Java 11 LTS installer package, using the SapMachine Java 11 LTS receipt’s BOM, and identified those files which were not included in the SapMachine Java 17 LTS installer package’s BOM.
4. Removes those files.
5. Adds the files from the SapMachine Java 17 LTS installer.

The effect is that SapMachine Java 11 LTS’s files were automatically removed when SapMachine Java 11 LTS is installed first and then SapMachine Java 17 LTS is subsequently installed.

The fix? Make sure the SapMachine Java 17 LTS installer package has a different package identifier.

As I was using AutoPkg to build the installer package in question, I could include variables as part of the package identifier to help ensure the package identifier would be unique for each version of the SapMachine Java 17 LTS installer package.

For example, for SapMachine Java 17.35 LTS, the package identifier looks like this in the AutoPkg-created installer package:

I’ve previously posted guides on how to manually package SAP GUI:

• Building an SAP GUI installer for macOS
• Packaging SAP GUI for macOS with Java 11 support
• Packaging a SAP GUI installer application for macOS

However it’s also possible to automate creating a SAP GUI installer package using AutoPkg. To do this, you’ll need the following:

1. AutoPkg
2. The SAP GUI recipes from the rtrouton-recipes repo
3. The latest SAP GUI installer application’s disk image
4. A SAP GUI templates.jar file (optional)

For more details, please see below the jump.

The AutoPkg recipes I’ve written will need the following information provided:

• SAP GUI’s numeric information
• SAP GUI’s alphanumeric information
• SAP GUI’s application bundle identifier information

None of this information is available from the installer application, so you’ll need to provide it to AutoPkg using a com.sapgui.identifier.plist file which will be included along with the latest SAP GUI installer application’s disk image. Please see below for how to gather this information.

Preparing SAP GUI for AutoPkg

1. Copy the latest SAP GUI installer application’s disk image to a test Mac or virtual machine.

2. Mount the disk image and launch the SAP GUI for Java Installer installer application on the test Mac or virtual machine.

3. Follow the prompts to install.

4. Once installed, run the following command to get SAP GUI’s alphanumeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" NSHumanReadableCopyright | awk '{print $2$3$4}'

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" NSHumanReadableCopyright| awk '{print $2$3$4}'

5. Once you have the alphanumeric version, run the following command to get SAP GUI’s numeric version.

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleShortVersionString

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleShortVersionString

6. Once you have both versions, run the following command to get SAP GUI’s bundle identifier:

defaults read "/Applications/SAP Clients/SAPGUI $version/SAPGUI $version.app/Contents/Info.plist" CFBundleIdentifier

For example, if this is SAPGUI 7.70rev2, use the following command:

defaults read "/Applications/SAP Clients/SAPGUI 7.70rev2/SAPGUI 7.70rev2.app/Contents/Info.plist" CFBundleIdentifier

7. Open Terminal and run the following command to create a com.sapgui.identifier.plist file with the alphanumeric version information for SAP GUI:

defaults write /path/to/com.sapgui.identifier AlphanumericVersionString version_info_goes_here

For example, if the SAP GUI alphanumeric version is 7.70rev2, run the following command to create a com.sapgui.identifier.plist file on the Desktop:

defaults write $HOME/Desktop/com.sapgui.identifier AlphanumericVersionString 7.70rev2

8. Run the following command to add the numeric version information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleShortVersionString version_info_goes_here

For example, if the SAP GUI numeric version is 770.4.200, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleShortVersionString 770.4.200

9. Run the following command to add the bundle identifier information for SAP GUI to the com.sapgui.identifier.plist file:

defaults write /path/to/com.sapgui.identifier CFBundleIdentifier bundle_identifier_info_goes_here

For example, if the SAP GUI bundle identifier is com.sap.platin, run the following command

defaults write $HOME/Desktop/com.sapgui.identifier CFBundleIdentifier com.sap.platin

10. Once the com.sapgui.identifier.plist file is created and populated with the version and bundle identifier information, copy it to a convenient location along with the latest SAP GUI installer application’s disk image.

11. If you’re planning to include a templates.jar file with the SAP GUI installer, copy the templates.jar file to the same location.

12. Create a .zip file of the following files:

• corp.sap.sapgui.identifier.plist
• Latest SAP GUI installer application’s disk image
• templates.jar (if applicable)

For this example, I’m going to use the following filename for the .zip file:

latestsapgui.zip

This .zip file will be what’s used by AutoPkg to create the SAP GUI installer package.

Using the AutoPkg recipes

To accomodate the fact that some folks will have a templates.jar file which they want to include and some folks won’t, I’ve written two sets of .pkg recipes:

• SAPGUIWithTemplate.pkg – Use when you’re using a templates.jar file
• SAPGUIWithoutTemplate.pkg – Use when you’re not using a templates.jar file

Both sets of recipes share a common SAPGUI.download recipe.

SAP GUI does not have a publicly accessible download link, so there are two options available for adding the .zip file you created earlier to your AutoPkg workflow:

1. Posting the .zip file to a web server for download.

You can upload the .zip file to a web server or other online storage location which AutoPkg can download files from. This is my preferred method because you can set the download URL in an AutoPkg override. Once that’s done, you just need to replace the .zip file on the web server when a new version of SAP GUI comes out. The next time it’s run, AutoPkg will download the new .zip file and handle the rest automatically.

2. Using AutoPkg’s -p option.

AutoPkg includes an -p option for specifying a file for input, in place of downloading from a URL.

For example, if you wanted to run the SAPGUIWithTemplate.pkg recipe and use a .zip file stored locally on your Mac, you would use the following command to run an AutoPkg override of the SAPGUIWithTemplate.pkg recipe and specify a .zip file named latestsapgui.zip:

autopkg run local.pkg.SAPGUIWithTemplate -p /path/to/latestsapgui.zip

Once you’ve sorted out how you’re adding the .zip file you created to your AutoPkg workflow, you should be able to use these recipes to create SAP GUI installer packages for use in your own environment.

For those who want to use code signing to sign the SAP GUI installers created by AutoPkg, I’ve also created the following .sign recipes:

SAPGUIWithTemplate.sign – Use when you’re using a templates.jar file
SAPGUIWithoutTemplate.sign – Use when you’re not using a templates.jar file

Each .sign recipe uses the appropriate .pkg recipe as a parent recipe.

As part of macOS Monterey, Apple has introduced the Erase All Contents and Settings function to macOS for Apple Silicon Macs. In my Monterey testing, this setting was very useful because it enabled me to reset my Mac to a factory default condition without having to spend extra time wiping the drive and installing a fresh copy of macOS.

However, having this functionality available may not desired in all environments. For Mac admins supporting these environments, Apple has provided a new profile management option, as part of the Restrictions payload, which disables the Erase All Contents and Settings functionality on Apple Silicon Macs.

For more details, please see below the jump.

I’ve written a profile to disable Erase All Contents and Settings functionality which does the following:

1. Removes the Erase All Contents and Settings… menu option from the System Preferences option.

2. Blocks the Erase Assistant app from running.

Note: When the profile is installed, the Erase Assistant app will show the following message:

Erase Assistant is not supported on this Mac.

In order to apply this profile, there are some pre-requisites:

• User Approved Mobile Device Management (UAMDM) must be enabled on the target Mac.
• Profile must be installed by an MDM server.

Those pre-requisites also apply to deploying this profile, which is available via the link below:

https://github.com/rtrouton/profiles/tree/main/DisableEraseAllContentsAndSettings

When deployed, the profile should appear similar to this in System Preference’s Profiles preference pane.

As part of the move from using kernel extensions to system extensions, there is an issue which can be a problem for Mac admins: Uninstalling a system extension from the command line usually involves a GUI window popping up and requesting admin authorization.

This can be a problem for admins because it requires the logged-in user to:

• Have admin rights.
• Understand what the dialog is telling them.
• Be willing to enter admin credentials when prompted.

For macOS Monterey, this issue has been addressed by the addition of the RemovableSystemExtensions property to the com.apple.system-extension-policy profile payload. This is used to identify system extensions which can be deactivated without requiring admin authorization.

However, the RemovableSystemExtensions property is new in macOS Monterey and does not apply to macOS Big Sur and earlier. In the past, Mac admins have dealt with this issue through user education, providing warnings like the one shown below, or (in macOS 11.3 and later) removing the profile which authorized the system extension. In the latter case, removing authorization will also unload the system extension.

However, there is a way to bypass the admin authorization. For more details, please see below the jump.

There are two parts to being able to silently uninstall a system extension. The first is that the app developer must have written into their code signed app a way to trigger Apple’s uninstall API for system extensions. An example of this can be found in the code of the open source Santa tool created by Google:

https://github.com/google/santa/blob/d2b6c2b6c2de33ba2267c54f9affcbf592046050/Source/santa/main.m#L64-L78

For Santa, this functionality can be triggered from the command line by running the following command:

/Applications/Santa.app/Contents/MacOS/santa --unload-system-extension

This call to Apple’s uninstall API must be from the same code-signed app which is using the system extension. Other applications or functions trying to call the uninstall function from outside the app will not be authorized to uninstall the system extension.

Assuming that the code is included in the app to trigger Apple’s uninstall API for system extensions, the next step is found in the authorization database as the setting which controls whether or not the logged-in user is prompted for admin credentials is located there. Running the following command should show the setting:

security authorizationdb read com.apple.system-extensions.admin

That should display output similar to what’s shown below:

The rule key’s value is what determines whether the logged-in user is asked for admin authorization:

By default, this value is set to the following:

authenticate-admin-nonshared

https://gist.github.com/rtrouton/bb4e4136af5ee1b8160f1638b68f1a86

However, this value can be changed. Setting it to the value shown below will stop the request for admin authorization:

allow

https://gist.github.com/rtrouton/dd26f434ff28edaac455b6b396b26e44

To change com.apple.system-extensions.admin‘s rule key value to allow, you can use the commands shown below:

To revert back to the default value of authenticate-admin-nonshared, you can use the commands shown below:

An example of how this can be used is with Microsoft Defender, which may deploy multiple system extensions. The example script below will uninstall Microsoft Defender and includes deactivating the system extensions without prompting the logged-in user for admin credentials:

Before Microsoft Defender uninstallation:

After Microsoft Defender uninstallation:

When legacy FileVault was first introduced as part of Mac OS X 10.3 Panther in 2005, it supported a recovery key method which used a special keychain named FileVaultMaster.keychain which by default had a private key and public key inside. This recovery key was used to provide certificate-based authentication to unlock the encrypted disk images which were used by legacy FileVault.

When FileVault 2 was announced as part of Mac OS X Lion in 2011, Apple announced that there would be two kinds of recovery keys available:

1. Personal recovery keys (PRK) – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.
2. Institutional recovery keys (IRK) – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.

IRKs were the sole part of Apple’s FileVault 1 (also known as legacy FileVault) that was carried over into FileVault 2. IRKs were legacy FileVault’s recovery keys and they were used in almost exactly the same way. The main difference was that they were now used to unlock an encrypted disk as opposed to legacy FileVault’s disk images.

In FileVault 1 deployments, you were asked to set a Master Password when turning on FileVault 1’s encryption. When you set the Master Password, the FileVault 1 encryption process set the password that was entered as the password on the /Library/Keychains/FileVaultMaster.keychain file. In turn, the FileVaultMaster.keychain file contained two keys used for PKI certificate-based authentication (one public key and one private key). When the public and private keys are both stored in one keychain, the keychain can be used to unlock your FileVault 1-encrypted home folder in the event that the password to open it was lost or forgotten. The Master Password only unlocked the keychain and allowed the system to access those two PKI keys. This is the reason why you needed to set the Master Password before encrypting and why it was also important to use the same FileVaultMaster.keychain file across the machines where you wanted to make sure that the same recovery key was being used.

If you were deploying the same recovery key for your FileVault-encrypted Macs, Apple consistently recommended that you go into the FileVaultMaster.keychain file, remove the PKI private key, put the private key somewhere secure and deploy the FileVaultMaster.keychain file with only the public key inside. The reason was that, in the event that the password to the FileVaultMaster.keychain file was compromised, all the compromiser got was one half of the keypair (the public key half.) The private key would not be on the machine and thus not available to compromise the FileVault 1-encrypted homes on the machine. However, FileVault 1 would work with both the public and private keys stored in /Library/Keychains/FileVaultMaster.keychain.

In FileVault 2, Apple changed removing the private key from being a suggested best practice to being a technical requirement. If you want to use an institutional recovery key, your FileVaultMaster.keychain file needs to have just the public key in it. If both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain and not use it as an institutional recovery key. In this case, enabling FileVault 2 encryption will automatically generate a personal recovery key.

That was then, this is now

Over the years, the PRK gained functionality while the IRK largely did not. With the advent of PRK escrow systems (found in most present-day MDM solutions), the IRK’s main advantage of being a recovery key which could be mass-deployed came to seen instead as a weakness. After all, better to have recovery keys where each encrypted drive has its own unique key in place of the danger of a compromised recovery key being able to unlock all the machines in your Mac environment.

You can also only use an IRK to unlock or decrypt if you were booted to macOS Recovery. Recovery’s limited functionality meant that users of an IRK would have to do some preparation work, including making sure that the IRK’s keychain file was available somewhere which could be reached from Recovery.

Meanwhile, Apple has made changes to the environments where you could use an IRK. Beginning with macOS Catalina, macOS Recovery now prompted you to log in with either a password associated with an admin user or with a PRK.

You could not use an IRK at this login screen. So now Mac admins found themselves in the situation where they had an IRK, but couldn’t use it to authenticate in Recovery and get to the point where they could use the IRK.

With the introduction of Apple Silicon Macs, Apple has also discontinued Target Disk Mode functionality. This also affected the use of IRKs because it removes the ability to unlock using an IRK while the locked drive is connected to another Mac via Target Disk Mode.

The combination of all of these factors has led to Apple making a written recommendation to not use IRKs for institutional deployments of FileVault on Macs.

It’s been a long run for IRKs and they still do work as recovery keys (for now), but in my opinion it’s time to follow Apple’s stated recommendation and stop the deployment and use of IRKs as FileVault recovery keys.

Every so often, I need to have Jamf Pro perform actions where it’s difficult to arrange the timing and task order I want using the options available from the Jamf Pro server’s end. An example of this would be following an OS upgrade. I want the following:

• Update the computer inventory record in Jamf Pro as soon as possible that the OS upgrade has occurred.
• Don’t interfere with any other processes that Jamf Pro may be running at that time.

To address this, I want to use the following workflow:

1. Make sure the Jamf Pro agent hasn’t run anything for at least the last five minutes.
2. Enforce the Jamf Pro agent’s management framework
3. Send the Jamf Pro server an updated inventory.

To run these tasks, I’m using a self-destructing LaunchDaemon and script. For more details, please see below the jump.

I’ve written an example script, which does the following:

• Creates a LaunchDaemon
• Creates a script in /var/root which is triggered to run by the LaunchDaemon

Once triggered to run, the script stored in /var/root verifies that the Mac can communicate with the Jamf Pro server. Once communication is verified, it takes the following actions:

• Checks to see if the /var/log/jamf.log file has been modified in the previous five minutes.
• Once it has been verified that the /var/log/jamf.log file has not been modified for at least the last five minutes, the script runs the following functions:

1. Runs jamf manage to enforce the management framework using the latest available data from the Jamf Pro server
2. Runs jamf recon to send an updated inventory to the Jamf Pro server
3. Deletes LaunchDaemon file
4. Deletes script file
5. Unloads LaunchDaemon

Note: The order for deletion and unloading is important. If the LaunchDaemon is unloaded before the script deletes the LaunchDaemon’s and script’s file, LaunchD will stop the script’s run at the point where the LaunchDaemon unload command occurred. Both the script and LaunchDaemon are in the computer’s memory, so it’s possible to delete the files before the script unloads the LaunchDaemon from LaunchD.

This script is available below and also from GitHub at the following location:

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

This technique is pretty flexible and can be used to trigger other tasks with Jamf Pro. One example would be triggering installation of a particular software package faster than usual. In this scenario, you may have a particular software installation which is a module for X software, but only members of a specific LDAP are supposed to get that module. So the module is set for installation on check-in and scoped as follows:

• Target: Macs with X software installed.
• Limitation: LDAP group
• Exclusion: Macs with Module Installed.

Your check-in is scheduled to happen every fifteen minutes, but you get feedback from management that this process can’t wait fifteen minutes. It needs to happen within five minutes or sooner. No problem; this technique can be adapted to do the following:

1. Runs jamf recon to send an updated inventory to the Jamf Pro server (to make sure that the module installation policy has the Mac in scope.)
2. Runs jamf policy to trigger installation of the module.
3. Deletes LaunchDaemon file
4. Deletes script file
5. Unloads LaunchDaemon

After that, add the script to your X Software install policy and set it to run as an After script. The module should now install within five minutes if installing X software was the last action taken by Jamf Pro.

An example script is available below: