Notarizing Automator applications

Apple recently updated their notarization documentation to include this note:

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

The part about “notarization will be required by default for all software” made me think, because there are a few apps that I’ve written over the years that are still useful (at least to me). All of them were built using Automator, which meant that the usual Xcode-based ways of notarizing applications wasn’t going to work for me.

With assistance by folks in the MacAdmins Slack though, I was able to develop a process that allowed me to do the following:

1. Codesign an Automator application
2. Upload the application to Apple for notarization
3. Attach the notarization to the application
4. Verify that the notarization was attached and valid.

The documentation linked below was also very helpful in figuring out how to notarize using command line tools:

• https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
• https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

For more details, please see below the jump.

Updated MigrateADMobileAccounttoLocalAccount script now available to fix password issue in macOS 10.14.4

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. I had to update it in 2018 to fix a bug, but once that issue was fixed, the script has chugged along without changes between macOS 10.13.5 and macOS 10.14.3.

However, starting with macOS 10.14.4, I was alerted to an issue with how the script worked in combination with a change on Apple’s end.

As part of the script, the following actions take place:

1. The password hash value of the account from the AuthenticationAuthority attribute of the relevant account is backed up.
2. The AuthenticationAuthority attribute is deleted from the relevant account.
3. The AuthenticationAuthority attribute is re-created and the password hash of the account is restored from the backup.

As of macOS 10.14.4, once the reference to the password hash is removed from the AuthenticationAuthority attribute, the actual password hash is now automatically deleted by the OS. That means that step 2 in the process described above actually causes the password for the account to be removed, so that the account’s password must be re-set.

How to fix this? For more details, please see below the jump.

Mounting Time Machine local snapshots as read-only volumes

Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) boot drives gained the ability to create APFS snapshots. These snapshots are stored on the boot volume, but are not the same as the local backups that Time Machine uses on HFS+-formatted drives.

On HFS+ formatted drives, Time Machine local backups are stored in an invisible directory named .MobileBackups on the root level of the boot drive.

In turn, this .MobileBackups directory is mountable as /Volumes/MobileBackups and you can access the backed-up files stored inside by navigating via the command line or Finder window.

On APFS-formatted drives, the /.MobileBackups directory and /Volumes/MobileBackups are no longer available. Instead, Time Machine is now using APFS snapshots to store a read-only copy of the state of your Mac at the time when that snapshot was taken. These snapshots are invisible to the file system, so unlike HFS+, there isn’t a directory or file you can access. Instead, you now need to use the mount_apfs command’s -s option to mount APFS snapshots as read-only volumes.

For more details, please see below the jump.

Mouse doesn’t move at FileVault login screen in VMware Fusion macOS Mojave VMs

As part of working with FileVault on macOS Mojave, I’ve been using VMs running in VMware Fusion 11.x for testing. As part of that, I’ve seen a problem where the mouse doesn’t move when the VM has booted to the FileVault login screen. The keyboard responds and arrow keys can be used to select users, but the mouse itself is immovable and does not respond.

After some research, I ran across someone who had the same issue and found a workaround. For more details, please see below the jump.

Re-syncing local account passwords and Secure Token on FileVault-encrypted Macs running macOS Mojave

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. As mentioned in a previous post, Secure Token can present some interesting problems for Mac admins who work with FileVault-encrypted laptops. Among the potential complications are these scenarios:

• “I changed the password for my local account, but only the old password is being taken at the FileVault login screen.”
• “We’ve lost the password to the only local user account with a Secure Token, so now we can’t enable any other accounts on this Mac for FileVault.”

Usually, this happens because the local account password in question was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until the past few days, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround for encrypted Macs which fixes the password problem and sorts out Secure Token in these scenarios. In both cases, a personal recovery key will be needed as the way to authorize the needed changes. For more details, please see below the jump.

Unable to enable FileVault on macOS Mojave

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. Secure Token can present some interesting complications for Mac admins and among them is this scenario:

“The laptop is decrypted, but we can’t re-enable FileVault now.”

Usually, this happens because the account password was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until today, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround that fixes the password problem and sorts out the Secure Token attribute for the account on a decrypted laptop. For more details, please see below the jump.

Providing access to macOS software updates via Jamf Pro’s Self Service

For a number of OS releases, Apple made both macOS software updates and Mac App Store (MAS) updates available via the MAS Updates page. I was able to use this to provide an easy way for customers to check for available software updates using Jamf Pro’s Self Service. 

As of macOS Mojave though, Apple moved macOS software updates to the Software Update preference pane in System Preferences.

Opening the Software Update preference pane will automatically trigger a check for available macOS updates, so it’s possible to approximate the previous behavior by running the following command without root privileges:

open /System/Library/PreferencePanes/SoftwareUpdate.prefPane

When this command is run via the command line, the following actions take place:

1. System Preferences launches
2. The Software Update preference pane automatically loads
3. The Mac automatically checks for macOS updates.

For folks using Jamf Pro, this command can be leveraged to provide a way for customers to easily check for macOS software updates on their own schedule. For more details, see below the jump.