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.

Kernel extension warning dialogs in macOS Catalina 10.15.4

As part of macOS Catalina 10.15.4, Apple has begun displaying a new dialog window message concerning third-party kernel extensions. macOS Catalina is the last macOS to fully support the use of kernel extensions and these messages are meant to notify users of the following:

• macOS had detected that a third-party kernel extension had been loaded.
• The loaded kernel extension would be incompatible with an unspecified future version of macOS

To further reinforce the message that kernel extensions are going away, Apple refers to them in the message window as “legacy system extensions”. System extensions were introduced as part of macOS Catalina and are Apple’s replacement for kernel extensions.

As of macOS 10.15.4, these messages are informational only and do not indicate that anything is wrong with the referenced third-party kernel extension. For more information, please see the link below:

https://support.apple.com/HT210999

Blocking the messages

For a number of managed environments, these messages can be prevented from appearing. As long as a third-party kernel extension is whitelisted using an appropriate configuration profile, the message for it should not appear.

For more information about whitelisting kernel extensions using a configuration profile, please see the links below:

https://derflounder.wordpress.com/2018/04/12/whitelisting-third-party-kernel-extensions-using-profiles/
https://support.fleetsmith.com/hc/en-us/articles/360037495013-What-is-a-kernel-extension-
https://support.apple.com/guide/mdm/kernel-extension-policy-mdm88f99b98a/web

Disabling telemetry for Microsoft’s Visual Studio Code

Recently, I was tasked with figuring out how to disable telemetry for Microsoft’s Visual Studio Code. Normally, you can disable telemetry in a Microsoft application through using a macOS configuration profile or by using a defaults command. In this case though, Microsoft bought Visual Studio Code along with the rest of Xamarin, and Xamarin had some different ideas on where and how to store settings.

In the case of Visual Studio Code, the command to disable telemetry is stored as a .json file in the following location:

/Users/username_here/Library/Application Support/Code/User/settings.json

After some research and some work with an open source tool named jq, I was able to figure out how to handle disabling the telemetry setting. For more details, please see below the jump.

Identifying which MDM server a Mac is enrolled with

Every so often, you may run across a Mac which is enrolled in an MDM server which is different from the one it should be. However, if you’re checking remotely, it may be difficult to identify which one it is.

To help with this task, there is a script available which will parse the MDM enrollment profile on your Mac and identify the DNS name of the MDM server. For more details, please see below the jump.

Jamf Pro Inventory Update and recon functions – alike, but not the same

As part of discussing the outcome of a troubleshooting session concerning Jamf Pro and profile deployment with a teammate, I learned that the two functions that Jamf Pro uses to update its computer inventory worked in a similar fashion, but they weren’t identical.

The differences turned out to be important for profile deployment. For more details, please see below the jump.

Apple making changes to maximum lifetime limits for SSL certificates as of September 2020

All SSL certificates have a set amount of time which they’re good for, which means that at some point they expire. As an example, the SSL certificate currently used by www.apple.com has the following expiration date and time:

Friday, October 23, 2020 at 8:00:00 AM Eastern Daylight Time

As of today, March 5th 2020, the maximum lifetime for publicly trusted SSL certificates is 825 days, or roughly 27 months.

Apple has announced that, starting on September 1, 2020 at 00:00 GMT/UTC, all new SSL certificates being issued by specific Root Certificate Authorities (Root CAs) must not have a maximum lifetime longer than 398 days, or roughly 13 months, in order to be accepted as a valid certificate on Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

What certificates are affected?

This does not affect all SSL certificates. It will affect certificates issued on or after the September 1, 2020 start date by the Root CAs which are preinstalled with Apple’s iOS, iPadOS, macOS, watchOS, and tvOS operating systems.

Since these CAs are installed along with the OS, the certificates issued by these Root CAs are trusted by Apple’s OSs without any additional work needed by the end user. These Root CAs include commercial SSL vendors like Go Daddy, DigiCert and other companies.

What certificates are not affected?

Certificates issued by the specified preinstalled Root CAs before the September 1, 2020 start date are not affected. If they have a lifespan longer than 398 days, Apple will continue to accept them as valid until their set expiration date as long as they were issued prior to September 1, 2020 at 00:00 GMT/UTC.

Certificates issued by Root CAs which do not come with the operating system are also not affected. So if your company, school or institution has their own Root CAs , SSL certificates issued by those CAs are not affected by the new maximum lifetime restriction. Those CAs can continue to issue SSL certificates with lifetimes longer than 398 days.

Note: These Root CAs are not trusted by default by Apple’s operating systems. Instead, the Root CA’s root certificate would need to be installed and set as a trusted root by either the user or a system administrator.

Does this affect anyone other than Apple?

As of now, this is a unilateral move by Apple which hasn’t been adopted by other vendors. That said, Google had proposed something similar in September 2019 so it would not be surprising to see Google also adopt this at some point.

Will this affect only web browsers?

SSL certificates are used by a variety of applications and tools to help provide secure communication, so the effects of this change will not be restricted to web browsers like Safari. Non-compliant certificates may result in network services or applications failing to work properly.