Using the Jamf Pro API to retrieve FileVault personal recovery keys

January 25, 2023 Leave a comment

As part of Jamf Pro 10.43’s release, Jamf has added the ability to access and retrieve FileVault personal recovery keys via the Jamf Pro API:

For those who want to use this new capability, I’ve written a script which uses the Jamf Pro Classic API and Jamf Pro API to take a list of Jamf Pro computer IDs from a plaintext file, retrieve the associated Macs’ FileVault personal recovery keys and generate a report in .tsv format.

For more details, please see below the jump.

Read more…

Verifying installer package signing and notarization using pkgutil

January 20, 2023 Leave a comment

Recently I needed a way to verify whether an installer package was signed and notarized. I’ve been using Apple’s stapler tool as my usual go-to for verifying notarization. However, the stapler tool needs for Xcode to to be installed and I needed a solution that worked regardless of Xcode or the Xcode Command Line Tools being installed on the Mac in question.

After some digging, I found that pkgutil‘s check-signature function on macOS Monterey and later works great for this and doesn’t have any dependencies on Xcode or the Xcode Command Line Tools. The pkgutil tool is installed as part of macOS and the check-signature function displays the following on Monterey and later:

If a package is not signed:

Screenshot 2023 01 20 at 10 25 38 AM

If a package is signed with a certificate:

Screenshot 2023 01 20 at 10 24 52 AM

If a package is signed with a certificate and trusted by Apple’s notarization service:

Screenshot 2023 01 20 at 10 23 29 AM

To use the check-signature function, you should be able to use the command shown below (substituting /path/to/installer.pkg with the actual directory path of the installer package you want to check.):


/usr/sbin/pkgutil –check-signature /path/to/installer.pkg

view raw

gistfile1.txt

hosted with ❤ by GitHub

Finding the version number of the Xcode command line tools using the softwareupdate command

January 18, 2023 1 comment

As part of making sure your development environment is up to date, it’s often helpful to know what version of Xcode or the Xcode Command Line Tools that you’re using. For Xcode, this is relatively straightforward as you can check Xcode.app‘s version number or you can use the command shown below:


xcodebuild -version

view raw

gistfile1.txt

hosted with ❤ by GitHub

On a Mac running Xcode, running that command should provide output similar to what’s shown below:


username@computername ~ % xcodebuild -version
Xcode 14.2
Build version 14C18
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, for the Xcode Command Line Tools, this process isn’t as straightforward. There isn’t a specific app to check for version information and running the command above results in the following output:


username@computername ~ % xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

So how can you determine the latest installed version of the Xcode Command Line Tools? One way is to use the softwareupdate command’s history function, which should show all of the versions of the Xcode Command Line Tools which have been installed. You can use the following command to display all the installations of the Xcode Command Line Tools:


softwareupdate –history | grep "Command Line Tools for Xcode"

view raw

gistfile1.txt

hosted with ❤ by GitHub

For example, since both Xcode Command Line Tools 12 and Xcode Command Line Tools 13 are available for macOS Big Sur 11.7.x, you may see output similar to what’s shown below on a Mac running Big Sur:


username@computername ~ % softwareupdate –history | grep "Command Line Tools for Xcode"
Command Line Tools for Xcode 12.5 09/21/2022, 15:04:54
Command Line Tools for Xcode 13.2 01/17/2023, 11:18:19
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

Since the latest installed version of the Xcode Command Line Tools should be listed at the bottom of the output from the softwareupdate command’s history function, you should be able to use the following command to get the version number of the latest installed version of the Xcode Command Line Tools:


softwareupdate –history | awk '/Command Line Tools for Xcode/ {print $6}' | tail -1

view raw

gistfile1.txt

hosted with ❤ by GitHub

As of the date of this post, the latest version of the Xcode Command Line Tools on macOS Ventura 13.1 is version 14.2, so you should see output similar to what’s shown below on a fully updated macOS 13.1 Mac running the latest version of the Xcode command line tools:


username@computername ~ % softwareupdate –history | awk '/Command Line Tools for Xcode/ {print $6}' | tail -1
14.2
username@computername ~ %

view raw

gistfile1.txt

hosted with ❤ by GitHub

Apple Device Management Second Edition book available for pre-order from Amazon

January 1, 2023 1 comment

As mentioned previously, Charles Edge and I are releasing a new Second Edition of our Apple Device Management book. I’m delighted to announce it’s available for pre-ordering on Amazon via the link below:

https://a.co/d/bnCAr5W

This quality publication, just like First Edition, is stuffed with useful information, sure to be a collectors’ item and suitable for any gift-giving occasion. Please order yours today!

Categories: Books, Personal

Identifying Mac laptops and desktops from the command line by checking for a built-in battery

December 26, 2022 9 comments

Every so often, it may be necessary for Mac admins to deploy a script that can apply different settings to Mac desktops and laptops. A good example may be using the pmset command to apply Energy Saver settings, where you may want to apply one set of power management settings to laptops and a different set to desktops.


#!/bin/bash
# Set separate power management settings for desktops and laptops
# If it's a laptop, the power management settings for "Battery" are set to have the computer sleep in 15 minutes,
# disk will spin down in 10 minutes, the display will sleep in 5 minutes and the display itself will dim to
# half-brightness before sleeping. While plugged into the AC adapter, the power management settings for "Charger"
# are set to have the computer never sleep, the disk doesn't spin down, the display sleeps after 30 minutes and
# the display dims before sleeping.
#
# If it's not a laptop (i.e. a desktop), the power management settings are set to have the computer never sleep,
# the disk doesn't spin down, the display sleeps after 30 minutes and the display dims before sleeping.
#
# Detects if this Mac is a laptop or not by checking the model ID for the word "Book" in the name.
IS_LAPTOP=$(/usr/sbin/system_profiler SPHardwareDataType | grep "Model Identifier" | grep "Book")
if [[ -n "$IS_LAPTOP" ]]; then
/usr/bin/pmset -b sleep 15 disksleep 10 displaysleep 5 halfdim 1
/usr/bin/pmset -c sleep 0 disksleep 0 displaysleep 30 halfdim 1
else
/usr/bin/pmset sleep 0 disksleep 0 displaysleep 30 halfdim 1
fi

view raw

powersetings.sh

hosted with ❤ by GitHub

In the example above, the Model Identifier information from the system_profiler command is used to help identify if the Mac is a desktop or laptop. In this case, the Model Identifier information is checked to see if the model identifier contains “Book”.

Screenshot 2022 12 23 at 5 51 44 PM

If it does, it’s a laptop. Otherwise, it’s a desktop:


/usr/sbin/system_profiler SPHardwareDataType | grep "Model Identifier" | grep "Book"

view raw

gistfile1.txt

hosted with ❤ by GitHub

However, the latest Mac laptops’ model identifier does not contain “Book”. This means that this identification method should no longer be considered reliable.

Screenshot 2022 12 23 at 5 40 48 PM

What’s an alternative way to check? One way is to use the ioreg command to see if the Mac in question has a built-in battery or not. Laptops will have a built-in battery and desktops will not. For more details, please see below the jump.

Read more…

When does the upgrade to macOS Ventura need admin rights?

December 19, 2022 Leave a comment

Upgrading to macOS Ventura from macOS Monterey or earlier seems like it should be a straightforward process.

1. Open System Preferences

2. Click on Software Update.

Screen Shot 2022 12 19 at 12 40 55 PM

3. If the macOS Ventura upgrade is listed there, click on the Upgrade Now button.

Screen Shot 2022 12 19 at 11 19 59 AM

However, you may get different upgrade experiences depending on whether you are running macOS 12.3 or later, or if you’re running macOS 12.21 or earlier.

macOS 12.3 or later:

1. You see a macOS Ventura installer which is around 6 GBs or less.

Screen Shot 2022 12 19 at 11 23 04 AM

2. When you click Upgrade Now, you are asked to authenticate as a user. Not as a user with administrator privileges, just as a user.

Screen Shot 2022 12 19 at 11 24 31 AM

macOS 12.21 or earlier

1. You see a macOS Ventura installer which is around 12 GBs or more.

Screen Shot 2022 12 19 at 11 18 59 AM

2. It downloads an Install macOS Ventura app to your Mac and installs it in /Applications.

Screen Shot 2022 12 19 at 12 31 54 PM

3. The Install macOS Ventura app automatically launches once download and installation of the application completes.

Screen Shot 2022 12 19 at 12 31 57 PM

4. Running the Install macOS Ventura app will prompt for a user with administrator privileges to authenticate before the upgrade proceeds.

Screen Shot 2022 12 19 at 12 32 17 PM

Why the difference? The reason is that Apple has developed a new software upgrade path to macOS Ventura for Macs running macOS 12.3 or later which doesn’t require the following:

  1. The need to run the macOS Ventura full installer
  2. The requirement to authenticate as an administrator before upgrading from macOS Monterey to macOS Ventura.

Apple did include additional logic for macOS Ventura upgrades for upgrading to Ventura 13.0.0 and 13.0.1, where if a Mac running macOS Monterey 12.3 or later was enrolled with an MDM management solution and was thus in supervised mode, the new software upgrade path was disabled for those Macs.

As of the release of macOS 13.1, this logic no longer applies and supervised Macs may be offered the new upgrade path (which doesn’t require admin rights to upgrade.) 

For more details about this, and information on how to block the macOS Ventura upgrade from appearing in Software Update if your organization needs more time, please see the Apple KBase article linked below:

My colleague Robert Hammen has also written on the topic of delaying upgrades, so if you’re interested in that topic, please see his Medium post linked below:

Categories: Mac administration, macOS

Using AutoPkg to build installers for Palo Alto’s GlobalProtect VPN software

December 11, 2022 Leave a comment

As part of some recent testing, I needed to do some work with Palo Alto’s GlobalProtect VPN software. Palo Alto provides an installer package for GlobalProtect, but it has some interesting characteristics as the installer includes three installation options. One is enabled by default and the other two are disabled by default.

The first configuration is the option to install GlobalProtect, the default enabled configuration:

Screenshot 2022 12 08 at 3 47 44 PM

The second configuration is the option to uninstall GlobalProtect, which is disabled by default:

Screenshot 2022 12 08 at 3 49 18 PM

The third configuration is the option to enable the System Extension for GlobalProtect, which is disabled by default:

Screenshot 2022 12 08 at 3 50 35 PM

Note: In the image above, I’ve done some photoshopping because checking the third option to enable the System Extension for GlobalProtect also enables the option to install GlobalProtect. I made the change to the image to hopefully make more clear which option I was discussing.

The options to uninstall GlobalProtect and enable the System Extension for GlobalProtect can be managed by using an installer choices XML file to selectively enable only the desired option. For example, here’s the installer choices XML file for enabling only the option to uninstall GlobalProtect:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<array>
<dict>
<key>attributeSetting</key>
<integer>1</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>second</string>
</dict>
<dict>
<key>attributeSetting</key>
<integer>1</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>com.paloaltonetworks.globalprotect.uninstall.pkg</string>
</dict>
</array>
</plist>

Here’s the installer choices XML file for enabling only the option to enable the System Extension for GlobalProtect:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<array>
<dict>
<key>attributeSetting</key>
<integer>1</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>third</string>
</dict>
<dict>
<key>attributeSetting</key>
<integer>1</integer>
<key>choiceAttribute</key>
<string>selected</string>
<key>choiceIdentifier</key>
<string>com.paloaltonetworks.globalprotect.systemext.pkg</string>
</dict>
</array>
</plist>

Using these options, I was able to build recipes for AutoPkg which would automatically build three installer packages:

  • An installer which installs GlobalProtect.
  • An installer which uninstalls GlobalProtect.
  • An installer which enables the System Extension for GlobalProtect.

The reason I chose to do this is that using AutoPkg to create these additional installer packages should help ensure any changes that Palo Alto makes to GlobalProtect’s uninstall and System Extension enablement will automatically be available whenever a new version of GlobalProtect is picked up by AutoPkg. In turn, this should save work for those deploying GlobalProtect because now they don’t need to figure out what may have changed between GlobalProtect releases. For more details, please see below the jump.

Read more…

Creating a NexThink uninstaller for deployment via Jamf Pro

December 4, 2022 Leave a comment

As a follow-up to my previous post on building an installer for NexThink Collector which could be deployed via Jamf Pro, I also needed to build an uninstaller for this software. Fortunately, NexThink ships an uninstaller script on the same disk image that it uses to ship its installer.

Screenshot 2022 12 03 at 3 31 46 PM

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing the following to run the uninstall process:

A. Mounting the disk image
B. Opening the Terminal application
C. Using the uninstaller script to run the uninstallation process.

Screenshot 2022 12 03 at 3 47 10 PM

In my case, I decided to do the following to deploy the uninstaller via Jamf Pro:

  1. Wrap the disk image inside a separate installer package.
  2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Use the uninstall script to uninstall the NexThink Collector software.
D. Unmount the disk image.

For more details, please see below the jump.

Read more…

Creating a NexThink installer for deployment via Jamf Pro

December 3, 2022 3 comments

A while back, I had to build an installer for NexThink Collector which could be deployed via Jamf Pro. NexThink can be interesting to deploy because the installation process:

  1. Involves an application named csi.app, which has a command line tool.
  2. The referenced csi app’s command line tool configures and runs an installer package.
  3. The command line tool also needs to reference a license file, which NexThink refers to as a CustomerKey file.

The CustomerKey file should look similar to what’s shown below:


—–BEGIN CUSTOMER KEY—–MIIDhzCCAm+gAwIBAgIEIa+KoTANBgkqhkiG9w0BAQsFADBbMScwJQYDVQQDDB5SZWdlcnkgU2VsZi1TaWduZWQgQ2VydGlmaWNhdGUxIzAhBgNVBAoMGlJlZ2VyeSwgaHR0cHM6Ly9yZWdlcnkuY29tMQswCQYDVQQGEwJVQTAgFw0yMjEyMDIwMDAwMDBaGA8yMTIyMTIwMjIwMDIxMFowSTEVMBMGA1UEAwwMbG9jYWxob3N0LmlvMSMwIQYDVQQKDBpSZWdlcnksIGh0dHBzOi8vcmVnZXJ5LmNvbTELMAkGA1UEBhMCVUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaKRW9KeX4wg/838FkxmzaBjqf1DeKD5GKEqhUKz0y78Wwnsv2zAXGM4UkdZJP9zHtC9/wFQT+lhclDlogxkU9lfMADV7nMdGL0GkJzwMQNS52dPNXDup7/d9yRkyjkV0Pf4t2fJF3igoNXFQuBvuArkNV6hfja2gOEczOSAaJ7L7qRnSahLjciJRaCuEPjwneh3krhOFT+djwuYJMIvBDEqs+gfp4OPDDBtVg2scUUGRmHsC+JAoK+JwqYwB9TNt+9hZtGfDqgZSHebXEfRTguhQpBj0mPTo76EahAbHbXJhV+efg3jt32pZ6qRl8ffrZAjefWEAnOMyXQ7fbL+bpAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zAfBgNVHSMEGDAWgBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zANBgkqhkiG9w0BAQsFAAOCAQEAhpbntg+nwhIKgRuUidu/wXn197Ah0Pd4CYYxG5dR9rg8nWObx4QO6ApIH91nUUQVuV6mSTFtfy4yNQzxaROgZP9hDNvhd78D/ewXxp6bN/Xkn+c7SWrs/b1vHb2Dr1sDP4F9SAOrCI6TdoYa8UNhPXXSTt8M/hGSB2oWOpT2FAb2IbdmdYhDaibcJwp+/Had1FLbeDZgdgYCFoZLjws/9E/pIXjSxBYAJLbaQZffrfO5jCe2KesE73iQatW2IPynsFifRGGoMHXVLOfsLA9c2KDGqDmnJ+PvsBSe9rIpSJYC4WjR5Mt8W88kQSj05b9NqCsXmmMDEbD8uVLyKvQihA==—–END CUSTOMER KEY—–

All the needed components with the exception of the CustomerKey file, which is different for each customer, ship on a disk image.

Screenshot 2022 12 02 at 3 31 46 PM

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing one of the following:

Graphical installation: Mounting the disk image, double-clicking on the installer package and following the prompts, entering the correct configuration information were needed.

Screenshot 2022 12 02 at 3 46 29 PM

 

Screenshot 2022 12 02 at 3 46 39 PM

Command line installation: Mounting the disk image, opening the Terminal application and using the csi app’s command line tool to configure the installer package and run the installation process.

Screenshot 2022 12 02 at 3 46 53 PM

 

Screenshot 2022 12 02 at 3 47 02 PM

 

For the Enterprise Deployment section of the application, the NexThink documentation says they support it but doesn’t provide information on how to do it.

Screenshot 2022 12 02 at 3 47 10 PM

In my case, I decided to do the following to deploy it via Jamf Pro:

  1. Wrap the disk image and CustomerKey file inside a separate installer package.
  2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Identify the location of the csi.app on the mounted disk image.
D. Identify the location of the CustomerKey file stored inside the installer package.
E. Use the csi app’s command line tool to configure and run the NexThink-provided installer package on the mounted disk image, to install the NexThink Collector software.
F. Unmount the disk image.

For more details, please see below the jump.

Read more…

Session videos from Jamf Nation User Conference 2022 now available

December 1, 2022 Leave a comment

Jamf has posted the session videos for Jamf Nation User Conference 2022, including the video for my Running Jamf Pro at Scale, from SAP with ❤️ session.

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

%d bloggers like this: