Archive
Using macOS installer disk images to boot VMware Fusion virtual machines to macOS Recovery
Booting a VMware Fusion virtual machine to the macOS Recovery environment can be challenging, as Fusion uses Command-R as a keyboard shortcut for restoring snapshots.
This is the same keyboard shortcut as booting to macOS Recovery for Intel Macs so if you’re not very fast, or you don’t have the virtual machine window selected correctly, you may be looking at an unwanted request to restore a snapshot instead of macOS Recovery.
Fortunately, there’s a workaround for this behavior which will reliably get you into macOS Recovery. 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:
- 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.
- 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.
Downloading and installing macOS Big Sur via macOS Recovery’s Terminal
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.
Running recoverydiagnose in macOS Recovery
Most Mac admins, especially those who file bug reports or who work with AppleCare Enterprise, are familiar with running the sysdiagnose tool to gather diagnostic information about a Mac they’re working on. Running sysdiagnose will trigger a large number of macOS’s performance and problem tracing tools and use their reports to assemble what amounts to a snapshot of your Mac’s complete state at the time you ran the sysdiagnose tool, which can be very useful to developers trying to trace down why a particular problem is occurring.
However, this tool only applies to a Mac’s regular OS. What if the problem you’re seeing is in the macOS Recovery environment? In that case, you can run the recoverydiagnose tool in macOS Recovery to gather similar data specifically for macOS Recovery-related problems. For more details, please see below the jump.
Using an Activation Lock bypass code from Jamf Pro to clear Activation Lock on a Mac
As part of macOS Catalina, Apple introduced Activation Lock for Macs. As on iOS, Activation Lock is an anti-theft feature designed to prevent activation of a Mac if it’s lost or stolen.
Activation Lock on Macs does have some requirements in order for it to work. The Mac must:
- Run macOS Catalina or later
- Use the Apple T2 Security chip
- Two-factor authentication must be enabled on the Apple ID used for enable Activation Lock.
- Secure Boot must be enabled with Full Security settings and Disallow booting from external media selected.
Once these requirements are satisfied, Activation Lock is automatically enabled when Apple’s Find My service is enabled.
However, having Activation Lock turn on when Find My is enabled can lead to situations where it’s enabled by an employee on company-owned equipment. When this happens, companies, schools or institutions need a way to bypass Activation Lock without needing to know anything about the Apple ID used by the employee.
To provide this bypass, Apple has made it possible for companies, schools and institutions to use their MDM solution to clear Activation Lock. For more details, please see below the jump:
Erasing a FileVault-encrypted T2-equipped Mac
Normally, reinstalling macOS on a Mac is a straightforward process:
1. Boot to macOS Recovery
2. Select Reinstall macOS from macOS Utilities.
3. Follow the onscreen instructions.
However, if you have a Mac equipped with a T2 chip where FileVault is turned on, there’s an extra step involved. When you boot to macOS Recovery on a T2 Mac with FileVault on, you will be prompted for the password of an account on the Mac which has admin privileges.
If you don’t have the password to any of the accounts which appear, you can select the Forget all passwords? option.
This will bring up a new screen where you can enter a FileVault Personal Recovery Key.
If you can provide either the account password or the personal recovery key, the next thing you should see is the macOS Utilities screen.
What if you don’t have either a password or a personal recovery key? Is your Mac now a paperweight? For more details, please see below the jump.
Booting to macOS Recovery or Diagnostics via Jamf Pro’s Self Service
One of the advantages provided by Jamf Pro’s Self Service is that you can use it to provide easy access to tools for your users or helpdesk folks. One such tool could be a script which helps folks boot to their Macs to one of the following Apple support services:
- Diagnostics / Apple Hardware Test: https://support.apple.com/HT202731
- macOS Recovery: https://support.apple.com/HT201314
For more details, please see below the jump.
Rebuilding your macOS Recovery volume or partition with create_macos_recovery
I recently got an email from a former colleague, requesting assistance with a problem they were seeing. They were cloning drives with macOS Catalina, but their cloning process was not including the Recovery volume. Was there a way to create a new Recovery volume on a macOS Catalina boot drive that didn’t have one?
I did some research on this and found that there was a script to do this on High Sierra and Mojave, but it didn’t appear to work anymore.
With some more digging, I was able to figure out why. The script was downloading and expanding a macOSUpd10.13.6.RecoveryHDUpdate.pkg installer package from Apple’s Software Update service in order to get access to a dm tool included with the installer package. This installer package was no longer available from the Software Update service, but a similar package named SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg with the same dm tool was available.
Once I verified that I could get the same results using the SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg installer package, I wrote a script (based on the original one I had found) to help automate the process of rebuilding a macOS Recovery volume or partition. For more details, please see below the jump.
Google Keystone update breaks Macs’ ability to boot if System Integrity Protection is disabled
On the evening of Monday, September 23rd, a number of film and TV editors started reporting that their workstations were not rebooting successfully. The problem was initially blamed on the Media Composer software sold by Avid.
On September 24th, more instances were reported and it became clear that this was not an issue restricted to Macs with Media Composer installed. After extensive checking and testing, the folks in the MacAdmins Slack were able to narrow down the issue to an update to Google’s Keystone software, which Google uses to update Google Chrome and other Google products on macOS.
The now-pulled Keystone update attempts to remove the /var symlink, which is usually protected by Apple’s System Integrity Protection (SIP) security feature.
On Macs where SIP was disabled, this protection did not apply and the Keystone update was able to remove the /var symlink. This symlink is not a directory itself, but points to another directory (/private/var) which contains software necessary for the operating system to boot and function correctly, so removing the /var symlink rendered the affected Macs unbootable.
As mentioned previously, Google has pulled the problematic Keystone update and has published instructions on how to remediate affected Macs. For more details, please see below the jump.
macOS, hyperthreading and Microarchitectural Data Sampling vulnerabilities
In 2018, vulnerabilities were publicly disclosed in computer processor architecture which affected the vast majority of desktops, laptops, mobile devices and servers. These vulnerabilities are referred to as Meltdown and Spectre. There is a lot of information available online about these vulnerabilities, but the cartoon below provides a decent summary of the issue:
On May 14th, 2019, additional Spectre vulnerabilities were disclosed using the name Microarchitectural Data Sampling (MDS). These vulnerabilities apply to desktop and laptop computers which use Intel processors. These processors are used by all modern Macs, but not by iOS or Apple Watch devices. These devices do not use Intel processors and instead use Apple’s own processors. For an excellent round-up of information on this developing issue, please see @zoocoup‘s post available via the link below:
https://mrmacintosh.com/mds-vulnerabilities-summary-for-macadmins-by-jason-broccardo
How to remediate this problem? For the details, please see below the jump.
Der Flounder 
Recent Comments