Jamf Pro server installer for macOS retirement planned for March 2022

To follow up on my earlier post on the Jamf Pro Server Installer for macOS being retired, Jamf has added the following to the Deprecations and Removals section of the Jamf Pro 10.35.0 release notes:

Support ending for the Jamf Pro Server Installer for macOS—Support for using the Jamf Pro Installer for macOS will be discontinued in a future release (estimated removal date: March 2022). Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. If you want to migrate your Jamf Pro server from macOS to Jamf Cloud, contact Jamf Support via Jamf Account. If you want to keep your server on premise, you can migrate your Jamf Pro server from macOS to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server article.

 

For those folks who are running on-premise Jamf Pro servers on Macs, I strongly recommend contacting Jamf Support and plan a migration if you haven’t already. As of January 14th, 2022, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:

	Recommended Configuration:
	Operating Systems:
	Windows Server 2019
	Ubuntu Server 20.04 LTS
	Red Hat Enterprise Linux 7.x
	Database software versions:
	MySQL 8.0 – InnoDB
	Amazon Aurora (MySQL 5.7 compatible)
	MySQL 5.7.13 or later – InnoDB
	Java version:
	OpenJDK 11
	Minimum Supported:
	Operating Systems:
	Windows Server 2016
	Windows Server 2012 R2
	Ubuntu Server 18.04 LTS
	macOS 10.15
	macOS 10.14
	Database software versions:
	MySQL 5.7.13 – InnoDB
	MySQL 5.7.13 on Amazon RDS – InnoDB
	Java version:
	Oracle Java 11

view raw

gistfile1.txt

hosted with ❤ by GitHub

Preventing user and location inventory information from being changed by the jamf binary’s recon verb

You can allow or prevent local administrators on the computer from changing User and Location inventory information in Jamf Pro with the jamf binary by using the Allow local administrators to use the jamf binary recon verb to change User and Location inventory information in Jamf Pro checkbox. This is a feature which first appeared in Jamf Pro 10.20.x, but may not be well known.

This setting is enabled by default and can be configured by navigating to Settings > Computer Management > Inventory Collection in Jamf Pro.

What this setting affects are the following options associated with the jamf binary’s recon verb:

	-endUsername
	-realname
	-email
	-position
	-building
	-department
	-phone
	-room

view raw

gistfile1.txt

hosted with ❤ by GitHub

Why disable this setting? If you have workflows which leverage the user and location information stored in Jamf Pro, being able to change this setting from a managed Mac using the jamf binary’s recon verb may have security implications. In particular, PKI certificate authorities set up in Jamf Pro may use the user and location information stored in Jamf Pro to issue certificates to managed Macs.

In the context of certificates used for authentication, being able to change the user and location stored in Jamf Pro from the managed Mac’s end may mean that an enduser with the ability to run the jamf binary’s recon verb may be able to get authentication certificates for someone other than themselves assigned to their Mac.

If you do not have any workflows that use the recon verb’s options specified above, my advice is that you disable this setting and remove the ability of managed Macs to change the user and location information stored in Jamf Pro using the jamf binary’s recon verb.

Obtaining, checking and renewing Bearer Tokens for the Jamf Pro API

I’ve recently begun looking into uses for the Jamf Pro API, the API which Jamf makes available for Jamf Pro in addition to the Classic API. The two APIs handle authentication differently and for folks coming over to using the Jamf Pro API from the Classic API, the extra steps involved may be a surprise.

For the Classic API, here’s what’s required for authentication:

• One step process.
• Only username and password needed to authenticate an API call.
• Username and password can be in plaintext.
• No tokens are used.

Example Classic API call process:

	# Provide username and password as part of the API call:
	/usr/bin/curl -su username_here:password_here" -H "Accept: application/xml" https://server.name.here/JSSResource/packages/id/2

view raw

gistfile1.txt

hosted with ❤ by GitHub

For the Jamf Pro API, here’s what’s required for authentication:

• Multi-step process involving multiple API calls.
• Username and password only used to get authentication token, known as a Bearer Token. The Bearer Token is subsequently used for authentication.
• Username and password must be base64-encoded.
• Bearer Tokens are valid for 30 minutes maximum.
• Introduces need to validate authentication Bearer Tokens before making an API call.

Example Jamf Pro API call process:

	# Get username and password encoded in base64 format and stored as a variable in a script:
	encodedCredentials=$(printf username_here:password_here | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i -)
	# Use encoded username and password to request a token with an API call and store the output as a variable in a script:
	authToken=$(/usr/bin/curl https://server.name.here/api/v1/auth/token –silent –request POST –header "Authorization: Basic ${encodedCredentials}”)
	# Read the output, extract the token information and store the token information as a variable in a script:
	api_token=$(/usr/bin/plutil -extract token raw -o – – <<< “$authToken”)
	# Verify that the token is valid and unexpired by making a separate API call, checking the HTTP status code and storing status code information as a variable in a script:
	api_authentication_check=$(/usr/bin/curl –write-out %{http_code} –silent –output /dev/null https://server.name.here/api/v1/auth –request GET –header "Authorization: Bearer ${api_token}")
	#Assuming token is verified to be valid, use the token information to make an API call:
	/usr/bin/curl –silent -H "Accept: application/xml" –header "Authorization: Bearer ${api_token}" https://server.name.here/JSSResource/packages/id/2

view raw

gistfile1.txt

hosted with ❤ by GitHub

The differences in authentication are significant enough that I decided to write functions for shell scripting to handle the following tasks for the Jamf Pro API:

• Obtaining Bearer Token.
• Verifying that current Bearer Token is valid and unexpired.
• Renewing Bearer Tokens by using current Bearer Token to authenticate the issuing of a new Bearer Token. (This renewal process creates a new Bearer Token and invalidates the old Bearer Token.)
• Invalidating current Bearer Token.

For more details, please see below the jump.

Disabling Recent Tags in the Finder window sidebar

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. The Tags section of the Finder’s sidebar is one of those additions.

Fortunately for my preferences, I recently figured out (thanks to Bob Gendler’s method for discovering settings via the unified logs) that display of the Tags section was controlled via the following setting:

Domain: com.apple.finder
Key: ShowRecentTags
Value: Boolean

To show Recent Tags in the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool true

Here’s how the Recent Tags setting should now appear in the Finder preferences:

 

To remove Recent Tags from the Finder’s sidebar, run the following command as the logged-in user:

defaults write com.apple.Finder ShowRecentTags -bool false

 

Here’s how the Recent Tags setting should now appear in the Finder preferences:

 

The new setting will not apply until the Finder is restarted, which can be accomplished via either logging out and logging back in or running the following command as the logged-in user:

killall Finder

 

After the Finder restart, the Tags section should no longer appear in the Finder window sidebar:

 

In my case, I wanted them off permanently so I’ve also written a profile which can enforce this. It’s available via the link below:

https://github.com/rtrouton/profiles/blob/main/DisableRecentTagsinFinderSidebar

Session videos from Jamf Nation User Conference 2021 now available

Jamf has posted the session videos for from Jamf Nation User Conference 2021, including the video for my AutoPkg In The Cloud session.

For those interested, all of the the JNUC 2021 session videos are available on YouTube. For convenience, I’ve linked my session here.

Running Jamf Pro actions from outside Jamf Pro

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.

Use of FileVault Institutional Recovery Keys no longer recommended by Apple

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.

Silently uninstalling system extensions on macOS Monterey and earlier

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.

Disabling the Erase All Contents and Settings function on macOS Monterey

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.

Using AutoPkg to create an installer package for SAP GUI

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.