Creating a sysdiagnose file using Activity Monitor

The sysdiagnose tool is used for gathering a large amount of diagnostic files and logging, and it’s often very useful when it comes to figuring out why a problem is happening. However, it can sometimes be challenging to get a sysdiagnose-generated file from someone who is not comfortable with using the Terminal as the usual method for generating a sysdiagnose file involves opening the Terminal and running commands there.

Fortunately, there’s also a way to generate a sysdiagnose file using Activity Monitor. This may be an alternate way to help get you the desired sysdiagnose file from someone who normally wouldn’t ever use the Terminal on macOS. For more details, please see below the jump.

Granting Volume Owner status on Apple Silicon Macs

macOS on Apple Silicon Macs includes a concept known as volume ownership. You must be a volume owner to perform the following tasks on an Apple Silicon Mac:

• Make changes to startup security policy for a specific install of macOS.*
• Be able to authorize the installation of macOS software updates or macOS upgrades.
• Authorize running Erase All Contents and Settings.

* There may be multiple installations of macOS on one Apple Silicon Mac; each macOS install would have their own startup security policy.

For more information on volume ownership, please see Apple’s Platform Deployment article linked below:

https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e/web (see the Volume ownership section.)

How do you get volume ownership though? It turns out that Apple has this currently set up on macOS as a two-fer deal: If an account account has Secure Token, it is also granted volume ownership. For more details, please see below the jump.

Setting a user account to automatically log in using sysadminctl on macOS Ventura

On macOS, it’s possible to set an account to automatically log in. However, up until macOS Ventura, there hasn’t been an Apple command line tool available which will do the following:

• Set the desired account to automatically log in
• Create the /etc/kcpassword file

Setting the desired account to log in could be accomplished by running the following command with root privileges:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser -string username_goes_here

view raw

gistfile1.txt

hosted with ❤ by GitHub

The hard part was correctly creating the /etc/kcpassword file, which stores an obfuscated copy of the password used by the account which is being set for auto-login. Without that file properly created and available in the specified location, the automatic login process would fail. For those interested in how the kcpassword file is set up, please see the link below:

https://www.offsec.com/offsec/in-the-hunt-for-the-auto-login-setup-process/

There have been several tools built by the community which successfully create the kcpassword file, but Apple themselves hadn’t provided a way to do this in macOS Monterey or earlier, outside of using the GUI for Users & Groups in System Preferences.

As of macOS Ventura, the sysadminctl command line tool has been updated with functionality to enable and disable auto-login for specified accounts. For more details, please see below the jump.

Certificate expiration affecting macOS App Store and VPP apps

Mac admins who have previously installed macOS apps from the Mac App Store (MAS) or the Volume Purchase Program (VPP) may be seeing some of those apps displaying warning messages on launch that the application is damaged.

When observed, this behavior may be appearing because the certificates Apple has been using to digitally sign apps have recently expired, on February 6th 2023 or February 7th 2023. (Both expiration dates have appeared in signing certificates on the apps I’ve checked.)

When the code signing is detected as being invalid, Apple’s security tools are blocking launch as a consequence. In most cases, it appears that the code signing is still appearing as valid despite being past the expiration date.

---

Update: February 13, 2023 – I’ve received feedback from @macmuleblog after posting that they have seen damaged apps from VPP where they had a valid code signing certificate, so the root cause for the damaged apps may be different than what I initially posted. My apologies for any confusion caused.

---

Both the Apple Mac OS Application Signing certificate used to sign the apps, and the Apple Worldwide Developer Relations Certification Authority intermediate certificate are showing expiration dates that are now in the past.

In the cases where I’ve experienced applications reporting as damaged, uninstalling the app and reinstalling it seems to have addressed the issue. Hopefully Apple is working on getting the issue handled by re-issuing apps which are signed with a certificate signed with a new expiration date in the future.

---

Update: February 13, 2023 – It looks like Apple had previously begun the code signing effort I requested above. When I checked Microsoft’s To Do app, I saw that the Apple Mac OS Application Signing certificate used to sign the app and the Apple Worldwide Developer Relations Certification Authority intermediate certificate are showing expiration dates in the future.

---

Using the Jamf Pro API to retrieve FileVault personal recovery keys

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:

• Return FileVault information for a specific computer: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-id-filevault
• Return paginated FileVault information for all computers: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-filevault

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.

Verifying installer package signing and notarization using pkgutil

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:

If a package is signed with a certificate:

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

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

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

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

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”.

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.

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.

When does the upgrade to macOS Ventura need admin rights?

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.

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

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.

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.

macOS 12.21 or earlier

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

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

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

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

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:

• Manage upgrading to macOS Ventura in your organization: https://support.apple.com/HT213471

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:

• Holding Back the OS Upgrades: https://hammen.medium.com/holding-back-the-os-upgrades-6c2d97f99ac3

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

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:

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

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

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>

view raw

uninstall_global_protect.xml

hosted with ❤ by GitHub

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>

view raw

install_system_extensions.xml

hosted with ❤ by GitHub

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.