The T2 Macs, the end of NetBoot and deploying from macOS Recovery

In late 2017, Apple released the iMac Pro. Along with the new Secure Enclave protection provided by Apple’s T2 chip, the iMac Pro brought another notable development: It did not support booting from a network volume, otherwise known as NetBoot.

The one exception was Apple’s Internet Recovery, where Apple is providing a NetBoot-like service to provide access to macOS Recovery. The iMac Pro is still able to boot to Internet Recovery, which provides a way to repair the Mac or reinstall the operating system in situations where the Mac’s own Recovery volume is missing or not working properly.

With NetBoot not being available for the iMac Pro but still available for other models, it wasn’t yet clear if NetBoot-based workflows for setting up new Macs or rebuilding existing ones were on the way out. However, Apple’s release of of T2-equipped MacBook Pros in July 2018 which also could not use NetBoot has made Apple’s direction clear. As Apple releases new Mac models equipped with T2 chips and Secure Enclave, it is unlikely that these future Mac releases will be supporting NetBoot.

For Mac admins using NetBoot-based workflows to set up their Macs, what are the alternatives? Apple has been encouraging the use of Apple’s Device Enrollment Program, which leverages a company, school or institutions’ mobile device management (MDM) service. In this case, you would need to arrange with Apple or an Apple reseller to purchase Macs that are enrolled in your organization’s DEP.

When a DEP-enrolled Mac is started for the first time (or started after an OS reinstall), it is automatically configured to use your organizations’ MDM service and the device checks in with the MDM service. The MDM service then configures the Mac as desired with your organization’s software and configuration settings. A good example of what this process may look like can be seen here.

What if you don’t have DEP, or you don’t have MDM? In that case, you may still be able to leverage Recovery-based deployment methods, which would allow you install the desired software and configuration settings onto the Mac’s existing OS, or install a new OS along with software and configuration settings. For more details on these methods, please see below the jump.

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

We had users who couldn't log back in after upgrading to High Sierra, as it turns out due to superfluous quoting in the AD unbinding script.

— Per Olofsson (@MagerValp) June 15, 2018

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

The kicker was that they could log back in after unbinding to AD back in February. It was a ticking time bomb though, which blew up after the High Sierra upgrade.

— Per Olofsson (@MagerValp) June 15, 2018

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

Updated Xcode command line tools installer script now available

A while back, I developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher.

Most of the time it works fine. However, starting with macOS Sierra and continuing on with macOS High Sierra, I occasionally ran into an odd problem. Apple would sometimes have both the latest available Xcode Command Line Tools installer and the just-previous version available on Apple’s Software Update feed.

The original script was written with the assumption that there would only be one qualifying Xcode Command Line Tools install option available at any one time. When more than one is available, the script isn’t able to correctly identify which Xcode Command Line Tools it should be installing. The result is that the script ends without installing anything.

Apple usually removes the previous version from the Software Update feed within a few days, which allows the script to work normally again. But when it happened this time, I decided to update the script to hopefully fix this issue once and for all. For more details, please see below the jump.

Detecting if a logged-in user on a FileVault-encrypted Mac has a Secure Token associated with their account

A challenge many Mac admins have been dealing with is the introduction of the Secure Token attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume.

In my own shop, we wanted to be able to identify if the primary user of a Mac had a Secure Token associated with their account. The reason we did this was:

1. We could alert the affected help desk staff.
2. We could work with our users to rebuild their Macs on an agreed-upon schedule where their data was preserved.
3. We could hopefully avoid working with our users on an emergency basis where their data could be lost.

To help with this, we developed a detection script. For more details, please see below the jump.

Oracle Java 10 JDK and JRE installation scripts for macOS

Oracle has started to release Java 10 for macOS, so I’m posting a couple of scripts to download and install the following:

• Oracle Java 10 JDK
• Oracle Java 10 JRE

Oracle has been releasing two separate versions of Java 8 simultaneously and may do the same for Java 10, so these Java 10-focused scripts are designed to allow the user to set which version they want to install: the CPU release or the PSU release.

The difference between CPU and PSU releases is as follows:

• Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
• Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.

For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, please see below the jump.

32-bit application alert message in macOS 10.13.4

Starting on April 12, 2018, Macs running macOS 10.13.4 will display a one-time alert when 32-bit applications are opened. This alert will appear once per user account on the Mac, when a relevant 32-bit application is opened.

When the Learn More… button in the alert window is clicked, the following Apple KBase article opens in your default web browser:

32-bit app compatibility with macOS High Sierra 10.13.4
https://support.apple.com/HT208436

 

For those who need to stop this alert from being displayed in their environments, I’ve built a management profile to suppress the warning. It is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/Disable32BitApplicationWarning

Whitelisting third-party kernel extensions using profiles

As part of macOS 10.13.2, Apple introduced the concept of User Approved MDM Enrollment (UAMDM). UAMDM grants mobile device management (MDM) additional management privileges, beyond what is allowed for macOS MDM enrollments which have not been “user approved”.

As of macOS 10.13.4, the only additional management privilege associated with UAMDM is that it allows you to deploy a profile which provides a whitelist for third-party kernel extensions. This profile allows a company, school or institution to avoid the need to have individual users approve the running of approved software.

Without the profile, third-party kernel extensions will need to be approved through the User-Approved Kernel Extension Loading (UAKEL) process. Here’s how that process looks:

1. When a request is made to the OS to load a third-party kernel extension which the user has not yet approved, the load request is denied and macOS presents an alert to the user.

2. The alert tells the user how to approve the loading of the kernel extension signed by a particular developer or vendor, by following this procedure:

A. Open System Preferences
B. Go to the Security & Privacy preference pane

C. Click the Allow button.

Note: This approval is only available for 30 minutes. After that, it disappears until the following happens:

i. The Mac restarts
ii. Another attempt is made to load the kernel extension.

While waiting for the kernel extension to be approved, a copy of the kernel extension is made by the operating system and stored in the following location:

/Library/StagedExtensions

Once approved, another copy of the kernel extension is made and allowed to load.

This process is relatively easy for an individual to manage on their own computer, but it would be very difficult to manage when dealing with more than a handful of Macs. To help companies, schools and institutions, Apple has made a management profile option available to centrally approve third-party kernel extensions. For more details, please see below the jump.