A while back, I wrote a post on how to enable automatic OS X updates on OS X Yosemite. The methods used to enable automatic macOS updates changed as of macOS Mojave, so let’s take a look at the changes. For more details, please see below the jump.

The main change is that the option to enable automatic macOS updates has moved from the com.apple.commerce preference domain to the com.apple.SoftwareUpdate preference domain. On OS X Yosemite through macOS High Sierra, the following command can be run with root privileges to enable OS X and macOS updates to be installed automatically:

defaults write /Library/Preferences/com.apple.commerce AutoUpdateRestartRequired -bool true

When this command is run, the following checkbox should be checked in the App Store preferences in System Preferences.

For Yosemite and El Capitan:

• Install OS X updates

For Sierra and High Sierra:

• Install macOS updates

As of macOS Mojave, the following command can be run with root privileges to enable macOS updates to be installed automatically:

defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticallyInstallMacOSUpdates -bool true

When this command is run, the following checkbox should be checked in the Software Update preferences in System Preferences.

• Install macOS updates

In both cases, the Mac will check for new updates overnight and install them when the Mac is idle. If a reboot is needed as part of installing an update, the Mac will reboot automatically.

If the Mac is not idle and a reboot is needed, a notification will appear to the logged-in user asking permission to reboot.

On OS X Yosemite through macOS High Sierra, the notification should look similar to this:

On macOS Mojave, the notification should look similar to this:

Unfortunately, it is not yet possible to set these automatic update settings using a profile. The com.apple.commerce preference domain can’t be managed by a profile and the AutomaticallyInstallMacOSUpdates setting in the com.apple.SoftwareUpdate preference domain should be manageable with a profile, but for unknown reasons, it can’t be.

In place of a profile, I’ve written a script to set up automatic OS X / macOS updates for OS X Yosemite through macOS Mojave. This script enables the following options:

• Automatic background check for macOS software updates
• Automatic download of macOS software updates
• Automatic download and installation of XProtect, MRT and Gatekeeper updates
• Automatic download and installation of automatic security updates
• Automatic installation of OS X / macOS updates for OS X Yosemite through macOS Mojave

The script is available below and also on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/enable_automatic_apple_software_updates

As part of working with FileVault on macOS Mojave, it may be necessary to decrypt an encrypted boot drive in order to fix a problem. On Mojave all boot volumes will use Apple File System (APFS), so to unlock or decrypt an encrypted boot drive from the command line, you will need to do the following:

1. Identify the relevant encrypted APFS volume
2. Unlock the encrypted APFS volume
3. If needed, decrypt the encrypted APFS volume

For more details, see below the jump.

Identifying the encrypted APFS volume

A necessary pre-requisite to unlocking APFS encryption is to identify the correct encrypted volume. To do this, open Terminal and run the following command:

diskutil apfs list

Running that command will give you a listing of all APFS containers and volumes. To help identify what you’re looking for, I’ve highlighted the identifier of the encrypted APFS volume in this example:

Unlocking the encrypted APFS volume

If you have access to the password of one of the enabled accounts on the encrypted APFS volume, you can unlock using the command shown on the screen. You will be prompted to provide the password.

diskutil apfs unlockVolume /dev/apfs_volume_id_goes_here

If you have access to the personal recovery key associated with the encrypted APFS volume, you can unlock using the command shown on the screen. You will need to provide the recovery key as part of the command.

diskutil apfs unlockVolume /dev/apfs_volume_id_goes_here -passphrase personal_recovery_key_goes_here

If using an institutional recovery key, you can unlock the encryption using a FileVaultMaster keychain that contains both the public and private key of your institutional recovery key. One requirement is that you will need to be booted from a Recovery HD partition or from Internet Recovery. Here’s how to do this:

1. Copy the FileVaultMaster keychain that contains both the public and private key of your institutional recovery key to a drive that you can access from Recovery HD.

2. Boot to Recovery HD.

3. Open Terminal.

4. Get the APFS volume ID of the encrypted drive by running the following command:

diskutil apfs list

5. With the APFS volume ID information acquired, run the following command to unlock the FileVaultMaster.keychain:

security unlock-keychain /path/to/FileVaultMaster.keychain

Once this command is run, you’ll need to enter the keychain’s password when prompted. If the password is accepted, you’ll be taken to the next prompt.

6. Run the following command to unlock the encrypted APFS volume on the encrypted Mac:

diskutil apfs unlockVolume /dev/apfs_volume_id_goes_here -recoverykeychain /path/to/FileVaultMaster.keychain

7. You should then see output similar to the following:

Decrypting the encrypted APFS volume

Once the drive has been unlocked, you can then decrypt the APFS volume. In order to decrypt using a user account’s password or a recovery key, it is necessary to specify the following:

1. The relevant encrypted APFS volume
2. The relevant user UUID, unless using an institutional recovery key.
3. The relevant account password, personal recovery key or institutional recovery key.

If you are planning to use a user account’s password to decrypt, you will first need to correctly identify the relevant encrypted APFS volume and which UUID you want to use. The encrypted APFS volume must also be unlocked and ready for decryption

You can get the UUID of a user account by running the command shown below and matching which UUID belongs to the account you want to use.

fdesetup list

If you are not booted from the encrypted drive, there is another way to get the UUID but it does not include the account name.

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

In this case, use the UUID associated with the Local Open Directory  User entry.

Unfortunately, this may lead to some guesswork on your part if there is more than one FileVault enabled account enabled. With multiple accounts enabled, there will be will be multiple Local Open Directory  User entries.

Decrypting using an account password:

Once you have access to the UUID and password of one of the enabled accounts on the encrypted APFS volume, you can decrypt using the command below. You will be prompted to provide the password:

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here

Decrypting using a personal recovery key:

If you want to use the personal recovery key, the PRK has its own UUID which only appears if you run the following command:

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

In this case, use the UUID associated with the Personal Recovery User entry.

If you have access to the personal recovery key associated with the encrypted APFS volume, you can decrypt using the command below. You will need to provide the relevant UUID and the alphanumeric recovery key as part of the command.

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here -passphrase personal_recovery_key_goes_here

Decrypting using an institutional recovery key:

If you want to use the institutional recovery key, decryption using an IRK does not require the use of UUIDs. Instead, once the recovery key and the encrypted drive have both been unlocked, you can decrypt using the command shown below.

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -recoverykeychain /path/to/filename_here.keychain

Monitoring decryption

You can monitor decryption of the APFS volume from the command line by running the following command:

diskutil apfs list

You can also monitor it via the following means:

1. Boot from the decrypting drive.
2. Open System Preferences
3. Open the Security & Privacy preference pane
4. Click the FileVault tab
5. View the current decryption status

In the event that you need to unlock an unbootable FileVault-encrypted boot drive on macOS Mojave, it’s possible to do so using Disk Utility and the password to a FileVault-enabled account on the drive.

For more details, see below the jump.

To unlock an encrypted boot drive, please use the procedure shown below:

Note: For this example, I’m using Recovery HD‘s Disk Utility though you can also use Disk Utility from a regular boot drive.

1. Open Disk Utility.

2. Select the locked encrypted drive.

3. Click the Mount button.

Alternatively, you can select the Mount command under the File menu.

4. In the password blank which appears, enter the password to a FileVault-enabled account on the drive.

5. If the authentication is accepted, the drive should unlock and mount.

Note: You will not be able to decrypt from Disk Utility on macOS Mojave. If decryption is necessary, you will need to use the command line method documented at the link below:

https://derflounder.wordpress.com/2019/01/15/unlock-or-decrypt-your-filevault-encrypted-boot-drive-from-the-command-line-on-macos-mojave/

One item of interest is that on macOS High Sierra, it is possible to unlock a FileVault-encrypted boot drive with Disk Utility using one of the following authentication credentials:

1. The password to a FileVault-enabled account on the drive
2. A personal recovery key

As of macOS Mojave 10.14.2, the ability to use a personal recovery key with Disk Utility to unlock an encrypted drive has apparently been removed.

A while back, I wrote a couple of scripts which built installers for Mac virtual machines:

• create_os_x_vm_install_dmg
• create_macos_vm_install_dmg

However, Apple made some changes to the macOS installer starting in macOS Sierra 10.12.4 which broke the method I was using to build the installers. Recently though, I figured out that I could use Apple’s createinstallmedia tool to help me with building installers for Mac virtual machines again. After a substantial re-write, create_macos_vm_install_dmg is able to create bootable disk images for virtual machines running macOS Sierra, High Sierra and Mojave.

One change from the previous version of the create_macos_vm_install_dmg script is that the resulting installer no longer runs an automated installation. Instead, it will be necessary to follow the prompts to select the language and drive to install the OS onto. For more details, please see below the jump.

Downloading the script

The create_macos_vm_install_dmg script is available from the following location:

https://github.com/rtrouton/create_macos_vm_install_dmg

Once you have the script downloaded, run the create_macos_vm_install_dmg script with two arguments:

• The path to an Install macOS.app.
• A directory to store the completed disk image in.

Using the script

If you have a macOS Mojave 10.14.3 installer application available in your Mac’s /Applications directory, run this command:

/path/to/create_macos_vm_install_dmg.sh "/Applications/Install macOS Mojave.app" /path/to/output_directory

If you had chosen to not create the .iso file, this should produce a .dmg file inside the specified output directory named macOS_10143_installer.dmg. This disk image will install a stock factory install of macOS 10.14.3.

If you chose the option to create the additional .iso disk image, you should have two files inside the chosen directory: macOS_10143_installer.dmg and macOS_10143_installer.iso

Creating a VM with the OS installer disk image using VMware Fusion 11.x

1. Launch VMWare Fusion 11.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select your macOS installer disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

Operating System: Apple OS X

Version: macOS 10.14

7. In the Finish window, select Customize Settings if desired.

Otherwise, click the Finish button.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the macOS installer disk image. To install macOS, start the VM and then run through the normal installation process when prompted.

Over the past couple of OS releases, Apple has made it increasingly clear that 32-bit applications are on the way out. Starting with macOS High Sierra 10.13.4, launching a 32-bit application for the first time will result in a message similar to this being displayed:

macOS High Sierra 10.13.4 and later

macOS Mojave 10.14.x

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 and later
https://support.apple.com/HT208436

To help identify if and where 32-bit applications have been installed, you can use /Applications/Utilities/System Information.app‘s list of installed software to identify which installed applications show up with the following status:

64-Bit (Intel): No

To assist with automating this task, a script is available which uses the /usr/sbin/system_profiler command line tool to detect all 32-bit apps installed in /Applications, /Library or /usr/local and output the list to a logfile stored in /var/log. For more details, please see below the jump.

The script does the following:

1. Checks to see if the script is being run as root.
2. Checks to see if the designated log file is present and creates it if it isn’t.
3. Uses /usr/sbin/system_profiler to pull the complete list of installed applications
4. Filters all applications that are not 64-Bit (Intel) applications.
5. Excludes all non-64-bit applications that are not stored in one of the following locations or their included directories:

/Applications
/Library
/usr/local

6. Outputs the following output to the log:

If any 32-bit applications are found in /Applications, /Library or /usr/local, the path to the delected 32-bit application or applications are listed in the log:

/path/to/32bit_application_name_here.app

If no 32-bit applications are found in /Applications, /Library or /usr/local, the following is output to the log:

No 32-bit applications found in /Applications, /Library or /usr/local.

The script is available below and also on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/detect_installed_32_bit_apps

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.

As an example of how this can be used, a Self Service policy can be built which uses the command referenced above.

• Frequency: Ongoing
• Trigger: None
• Make Policy Available In Self Service
• Actions:
• Execute command:

open /System/Library/PreferencePanes/SoftwareUpdate.prefPane

Note: For those looking for the Software Update icon on macOS Mojave, it is attached to the following application:

/System/Library/CoreServices/Software Update.app

Once built, the policy should be available in Self Service for your customers to access.

Please see below for what the process looks like from the customer’s perspective.

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.

To fix the account, the resetFileVaultpassword tool needs to be run from macOS Recovery. To access this tool, use the following procedure:

1. Boot to macOS Recovery.

2. Under the Utilities menu, select Terminal.

3. In Terminal, enter the following command and hit Enter.

resetFileVaultpassword

This will launch a Reset Password window behind the Terminal window.

If you just have one account on the Mac (which is likely if you find yourself in this scenario) the account should automatically be selected.

4. Enter a new password and verify it, then click the Next button.

5. When prompted, click the Restart button.

As part of the password reset process, the resetFileVaultpassword tool also resyncs the Secure Token attribute for the account. That should allow FileVault to work normally again.

Note: If you have multiple accounts on this Mac, the Reset Password tool requires all accounts’ passwords to be changed.

Following the reboot, you should now be able to enable FileVault on this Mac.

Thanks to the folks in the #security channel in the MacAdmins Slack for identifying and testing this workaround.

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.

Note: The methods described below only work with local accounts. Mobile accounts need to have password changes authorized by their parent directory service and directory services like Active Directory and Open Directory will not be accessible when using the tools and procedures described below.

There are two methods which can be used with a personal recovery key to reset a local account’s password and resync a Secure Token:

• FileVault login screen password reset
• macOS Recovery password reset

FileVault login screen password reset

At the FileVault login screen, the following procedure can be used to reset a local account’s password:

1. Select the user account in question.
2. Click the question mark icon.

3. Click the arrow icon.

4. Enter the personal recovery key in the provided blank, then click on the arrow icon.

The encryption will unlock at this point and the Mac will boot.

5. At the Reset Password dialog window, enter a new password and then click the Reset Password button.

As part of the password reset process, the Secure Token attribute for the account will also resync. That should allow FileVault to work normally again.

macOS Recovery password reset

In macOS Recovery, there is a resetFileVaultpassword tool which can use the personal recovery key to authorize password changes and Secure Token resync. The following procedure can be used to reset a local account’s password:

1. Boot to macOS Recovery.

2. Under the Utilities menu, select Terminal.

3. In Terminal, enter the following command and hit Enter.

resetFileVaultpassword

This will launch a Reset Password window, with a blank for entering the personal recovery key.

4. Enter the personal recovery key, then click the Next button.

5. Select the account whose password needs to be reset, then click the Next button.

6. Enter a new password and verify it, then click the Next button.

7. When prompted, click the Restart button.

As part of the password reset process, the resetFileVaultpassword tool also resyncs the Secure Token attribute for the account. That should allow FileVault to work normally again.

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.

By default, VMware Fusion 11.02 sets up VMs to use Hardware Version 16, which is the latest available.

Downgrading to Hardware Version 14 allows the mouse to move at the FileVault login screen again.

To downgrade hardware versions for your VM, please use the procedure shown below.

1. Shut down the VM.
2. Open the VM’s Settings window.
3. Select Compatibility
4. Click the arrow for Advanced options
5. Click on the Use Hardware Version: drop-down menu and select 14.
6. Click the Apply button.
7. Close the VM’s Settings window.
8. Start the VM.

The mouse should now move at the FileVault login window.

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.

To mount a Time Machine local snapshot as a read-only volume, you will need to first create a directory in a preferred location. This directory will act as the mount point for the snapshot.

For this example, a directory named snapshotbackup will be created in the /tmp directory.

Next, the snapshot to mount must be identified. The snapshots currently stored on the boot drive can be listed using the following command:

tmutil listlocalsnapshots /

For this example, the following snapshot will be used:

com.apple.TimeMachine.2019-02-23-102421

Once the mount point and snapshot have been identified, a command similar to the one shown below should mount the snapshot:

mount_apfs -s snapshot_name_here backed_up_volume_name_here mountpoint_name_here

For this example, the command should look like this:

mount_apfs -s com.apple.TimeMachine.2019-02-23-102421 / /tmp/snapshotbackup

The snapshot should then mount and appear as a read-only volume in the Finder.

To access the snapshot’s contents via the command line, you will need to access it via the mount point. For this example, this means the following directory path:

/tmp/snapshotbackup

Once finished with the snapshot, it can be unmounted via the command line or the Finder. To unmount via the command line, a command similar to the one shown below should unmount the snapshot:

diskutil unmount mountpoint_name_here

For our example, the following command will unmount the snapshot:

diskutil unmount /tmp/snapshotbackup

Yesterday, Jamf sent out the following notification in advance of the release of Jamf Pro 10.11.0:

One part of the message which caused some concern is this section:

Additionally, any LDAP server connections using LDAPS will require that the hostname of the LDAP server match the Common Name (CN) on the certificate that is uploaded to the Jamf Pro Server. A mismatch will prevent communication between the LDAP server and Jamf Pro Server.

What’s being referred to here is what’s known as an SSL hostname mismatch error, which is a sign that the SSL certificate being used to secure the connection isn’t configured correctly. But how can you tell with the SSL certificate used on an Active Directory domain controller? For more details, please see below the jump.

You can use the following openssl command to pull information about the SSL certificate used on your AD domain controller.

openssl s_client -connect servername_goes_here:636

You’ll need to replace servername_goes_here with the actual DNS hostname of your AD domain controller. For example, if your AD domain controller is named server.mycompany.local, you would use the following command:

openssl s_client -connect server.mycompany.local:636

When you run the command, you should get a block of text that looks similar to this:

Copy out the Server certificate section, between (and including) —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—— and put the copied text into a text editor.

From there, save it as a .cer file.

Once saved as a .cer file, you’ll be able to check the certificate using QuickLook and see what the certificate’s common name (CN) is.

One of the open-source contributions by the Apple@SAP team has been Privileges.app, a tool designed to grant or take away administrator rights from accounts on macOS. The general idea behind Privileges is that it allows people to work with the account privileges of a standard user for day-to-day use, but allows them to get administrator rights when needed.

Documentation for Privileges.app can be found at the GitHub repo which hosts it, which is available via the link below:

https://github.com/SAP/macOS-enterprise-privileges

However, one item not included in that documentation is how to package it for deployment. Instead, AutoPkg recipes were written and made available to automate the packaging process:

However, not everyone is able to use AutoPkg in their environment, so manual packaging instructions are now available here. For more details, please see below the jump:

Downloading the latest release of Privileges

Privileges.app is available for download from GitHub, via the following link:

https://github.com/SAP/macOS-enterprise-privileges/releases/latest

From there, click on the Privileges.zip download link.

Once uncompressed, Privileges.app is self-contained and can be installed via drag and drop.

Packaging Privileges.app

Pre-requisites:

• Packages
• The latest Privileges.app release

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project Privileges and storing the project files in my home folder.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

• Identifier: set as appropriate (for my installer, I’m using com.companyname.pkg.Privileges
• Version: set as appropriate (for my installer, I’m usings 1.0.3 )

In the Post-installation Behavior section:

• On Success: should be set to Do Nothing

In the Options section:

• Require admin password for installation should be checked
• Relocatable should be unchecked
• Overwrite directory permissions should be unchecked
• Follow symbolic links should be unchecked

7. Select the Payload tab.

8. Select the Applications directory.

9. Under the Hierarchy menu, select Add Files…

10. Select Privileges.app.

11. By default, the permissions for the app will be as follows:

Owner: root
Group: admin
Access: drwxr-xr-x

Change the permissions to match the following:

Owner: root
Group: wheel
Access: drwxr-xr-x

12. Select the Scripts tab.

The last part is adding a preinstall script and postinstall script. Here’s the preinstall script being used for this installer package:

If not already selected, select the preinstall script and add it to the project.

Note: This is the same preinstall script used by the AutoPkg .pkg recipe for Privileges.

Here’s the postinstall script being used for this installer package:

If not already selected, select the postinstall script and add it to the project.

Note: This is the same postinstall script used by the AutoPkg .pkg recipe for Privileges.

13. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Does not have Privileges.app installed

The end result should be that Privileges.app installs into /Applications and is able to do the following tasks:

1. Grant admin rights to a standard user
2. Take away admin rights from an admin user

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.

To address this issue, I’ve removed the parts of the script that do the following:

1. Back up the password hash value from the account’s AuthenticationAuthority attribute
2. Delete the account’s AuthenticationAuthority attribute
3. Re-create the account’s AuthenticationAuthority attribute and restore the password hash value.

In their place, I’ve added the following:

1. A function named PasswordMigration, which selectively edits the account’s AuthenticationAuthority attribute to remove the Kerberos and LocalCachedUser values

2. A call to the PasswordMigration function after the account attributes specified in the script are removed from the account.

Acknowledgements

My thanks to the folks who reported the issue and also provided the necessary fix. Regrettably, I can’t give them proper credit as they must remain anonymous.

Testing

This script has been tested and verified to migrate AD mobile accounts to local accounts on the following versions of macOS:

• macOS 10.14.4

In that testing, I did the following:

Testing on logged-in AD mobile user account:

1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
2. I logged into the AD mobile account and ran the script while logged in as that account.
3. Once the account had been migrated, I rebooted and verified that I could log in at the OS login window.
4. I changed the password for the local account to a new one and rebooted.
5. I verified that I could log in at the OS login window with the new password.

Testing on logged-out AD mobile user account:

1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
2. I logged into the VM using a local account which was not the AD mobile account and ran the script while logged in as that account.
3. Once the account had been migrated, I logged out and verified that I could log in at the OS login window with the just-migrated account.
4. I changed the password for the newly-migrated local account to a new one and rebooted.
5. I verified that I could log in at the OS login window with the new password.

Note: I did not test with FileVault-enabled accounts.

Advisory: Older versions of OS X and macOS were not tested and I have no idea if the script will work on those older OS versions.

Warning: I was able to test in my shop’s AD environment and verified that everything worked. That does not guarantee it will work in your environment. Test thoroughly before deploying in your own AD environment.

The updated script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_ad_mobile_account_to_local_account

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.

Pre-requisites

For notarization, you need the following things:

1. Xcode 10 or later installed on your Mac.
2. An Apple Developer Connection account
3. A one-time password for your ADC account’s Apple ID

As an example to use for the process, I’m using an existing Automator application that I wrote a while back:

• Payload-Free Package Creator.app

Notarization requires that the application in question be code signed and I had not yet done so for this application, so I needed to code sign my application first.

To do this, first clear the application of extended attributes by running a command like the one below:

sudo xattr -rc "/path/to/Application Name Here.app"

In my case, the command looked like this:

sudo xattr -rc "/Users/username/Desktop/Payload-Free Package Creator.app"

Once the application is ready for signing, run a command like the one below was run to code sign the application:

codesign --force --options runtime --deep --sign "Developer ID Application: Name Here (YG45FDT45F)" "/path/to/Application Name Here.app"

In my case, the command looked like this:

codesign --force --options runtime --deep --sign "Developer ID Application: Rich Trouton (XF95CST45F)" "/Users/username/Desktop/Payload-Free Package Creator.app"

Once signed, verify the signature using a command like the one below:

codesign -dv --verbose=4 "/path/to/Application Name Here.app"

In my case, the command looked like this:

codesign -dv --verbose=4 "/Users/username/Desktop/Payload-Free Package Creator.app"

Once finished, the output of the code signing looked like this:

The next thing needed is to get the app ready for upload to Apple for notarization. For this, you’ll need to do two things:

1. Have your one-time password for your ADC account ready.
2. Compress your application inside of a .zip file

Once your application has been compressed, run a command similar to the one below to upload it to Apple for notarization:

xcrun altool --notarize-app --primary-bundle-id "com.example.application.name" --username "adc_appleid_here" --password "adc_appleid_one_time_password_here" --file "/path/to/Application Name Here.zip"

In my case, the command looked like this:

xcrun altool --notarize-app --primary-bundle-id "com.apple.automator.Payload-FreePackageCreator" --username "adc_appleid_here" --password "one-time-password-goes-here" --file "/Users/username/Desktop/Payload-Free Package Creator.zip"

Once finished, the output of the notarization upload looked like this:

To validate that the notarization is successful, run a command similar to the one below:

xcrun altool --notarization-info uuid-goes-here --username "adc_appleid_here" --password "one-time-password-goes-here"

In my case, the command looked like this:

xcrun altool --notarization-info be136ed3-3888-44e1-87ed-0e5c8c13cdb5 --username "adc_appleid_here" --password "one-time-password-goes-here"

Once finished, the output of the notarization validation looked like this:

As part of the validation, a link to a log file is included. In my case, the log looks like this:

Once the notarization has been generated for the app, the next step is to attach, or staple, the notarization to the app. To do this, run a command similar to the one below:

xcrun stapler staple "/path/to/Application Name Here.zip"

In my case, the command looked like this:

xcrun stapler staple "/Users/username/Desktop/Payload-Free Package Creator.app"

Once finished, the output of the stapling process looked like this:

The final step is to validate that the stapling was successful. To do this, run a command similar to the one below:

stapler validate -v "/path/to/Application Name Here.zip"

In my case, the command looked like this:

stapler validate -v "/Users/username/Desktop/Payload-Free Package Creator.app"

Once finished, the output of the stapling validation looked like this:

Following notarization, Apple should send you a notification similar to the one shown below that your app has been notarized.

Starting with macOS High Sierra, Time Machine on Apple File System-formatted (APFS) startup drives gained the ability to create APFS snapshots. These snapshots capture the state of the startup volume at a particular point in time and can be used by Time Machine to restore files, folders or the whole startup volume. These snapshots are stored on the startup volume, but are not the same as the previous local backups that Time Machine used on Hierarchical File System Plus (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 startup drive.

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’s startup drive 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 location which you can access to get access to the snapshot-stored backups.

Snapshots include all files and directories stored on the startup drive at the time that the individual snapshot was made. When available, these snapshots can be used to restore the following:

• Individual files
• Individual directories
• Multiple files at once
• Multiple directories at once
• All files and directories at once

If the startup drive was encrypted at the time the snapshot was made, the snapshot will itself be encrypted. This allows the restoration of an encrypted startup drive without needing to decrypt or re-encrypt the relevant startup drive. For more details, please see below the jump.

Time Machine’s Snapshot Creation And Management

If you have Time Machine backups running on your Mac and your startup volume is APFS formatted, Time Machine will create snapshots automatically on the startup volume as part of its regular backup runs.

If you have Time Machine backups running on your Mac and your startup volume is APFS formatted, Time Machine will be creating snapshots on the startup volume as part of its regular backup runs. The creation and deletion of these snapshots is automatically managed by Time Machine, with Time Machine monitoring the age and size of the snapshots. Time Machine has the following rules for snapshot creation and deletion:

• One snapshot of the startup volume is created approximately every hour and kept for twenty four hours.
• At least one additional snapshot of the last successful Time Machine backup of the startup volume is kept.
• One snapshot of the startup volume is created before any software update which updates macOS to a new major or minor macOS version.

If startup volume space is needed by other functions, Time Machine will use these rules when determining which snapshots to delete from the startup volume and free up the needed space.

Using tmutil To Create And Manage Snapshots

You can use the tmutil command line tool to manage snapshots created by Time Machine. tmutil can perform the following functions:

• Creating new snapshots
• Listing existing snapshots
• Deleting existing snapshots
• Thinning existing snapshots to reclaim disk space

To create a new snapshot, the following command can be run:

tmutil localsnapshot

This command will create a new snapshot and tag it with the current date and time.

To list the new snapshot along with all other existing snapshots, tmutil’s listlocalsnapshots command will show all available snapshots stored on an APFS volume using a command similar to the one shown below.

tmutil listlocalsnapshots volume_name

For example, the following command can be run to list the available snapshots stored on the startup volume:

tmutil listlocalsnapshots /

To list snapshots by creation date, tmutil’s listlocalsnapshotdates command will show all available snapshots on all available APFS volumes, or all available snapshots on a specified volume.

The following command can be run to list the available snapshots’ creation dates on all available APFS volumes:

tmutil listlocalsnapshotdates

To display the creation dates of snapshots on a specified APFS volume, a command similar to the one shown below can be run to list the snapshots’ creation dates on that volume:

tmutil listlocalsnapshotdates volume_name

As an example, to display the creation dates of snapshots on the startup volume, the following command can be run:

tmutil listlocalsnapshotdates /

To delete existing snapshots, tmutil’s deletelocalsnapshots command can be used to remove snapshots stored on an APFS volume. These deletions are specified by date, using the following format:

YYYY-MM-DD-HHMMSS

Snapshots can be deleted using a command similar to the one shown below:

tmutil deletelocalsnapshots YYYY-MM-DD-HHMMSS

For example, the following command can be run to delete a snapshot with the creation date of 2019-04-23-134055:

tmutil deletelocalsnapshots 2019-04-23-134055

As an alternative to deleting snapshots, the tmutil command line tool also includes a thinlocalsnapshots function, which has the options shown below:

tmutil thinlocalsnapshots volume_name purge_amount urgency

Purge amounts are represented as bytes, so specifying 20 gigabytes of space would be represented by the following number:

21474836480.

Urgency levels are 1 through 4, with the default urgency setting being 1.

• Urgency level 4
• Most urgent – Any current backup processes are stopped and thinning is performed immediately. The largest available backup will be the first thinned, with thinning proceeding through the next largest backups.
• Urgency level 1
• Least urgent – Current backup processes will be completed before the thinning process begins. The oldest available backup will be thinned first, with thinning proceeding through the next oldest backups.

As an example, you would use the command shown below to free up 20 gigabytes of space from the snapshots stored on the startup drive at maximum urgency:

tmutil thinlocalsnapshots / 21474836480 4

The snapshot thinning process may take a while to run, depending on what would need to be done to free up the requested space. It may actually free up more than the requested space, but it should free up the requested space as a minimum if the stored snapshots are taking up at least that amount of drive space.

Restoring Files And Directories From Snapshots

When restoring files and directories from a snapshot, there are a couple of options. The primary option is to use Time Machine’s graphical interface to navigate the snapshot, then restore the desired files or directories.

Outside of the Time Machine graphical interface, there is also the option of mounting the snapshot as a read-only volume. This action can be performed using the mount_apfs command’s -s option to mount snapshots.

To mount a Time Machine local snapshot as a read-only volume, you will need to first create a directory in a preferred location. This directory will act as the mount point for the snapshot. For this example, a directory named snapshotbackup will be created in the /tmp directory by running the following command:

mkdir /tmp/snapshotbackup

Next, we need to identify which snapshot to mount. As previously mentioned, the snapshots currently stored on the startup drive can be listed using the following tmutil command:

tmutil listlocalsnapshots /

For this example, the following snapshot will be used:

com.apple.TimeMachine.2019-02-23-102421

Once the mount point and snapshot have been identified, a command similar to the one shown below should mount the snapshot:

mount_apfs -s snapshot_name backed_up_volume_name mountpoint_name

For this example, the command should look like this:

mount_apfs -s com.apple.TimeMachine.2019-02-23-102421 / /tmp/snapshotbackup

The snapshot should then mount and appear as a read-only volume in the Finder.

To access the snapshot’s contents via the command line, you will need to access it via the mount point. For this example, this means the following directory path:

/tmp/snapshotbackup

Once finished with the snapshot, it can be unmounted via the command line or the Finder.

To unmount via the command line, a command similar to the one shown below should unmount the snapshot:

diskutil unmount mountpoint_name

For our example, the following command will unmount the snapshot:

diskutil unmount /tmp/snapshotbackup

Performing Full System Restores From Snapshots

In addition to file and directory restores, Time Machine can perform full system restores from snapshots of startup volumes. These full system restores are run from the Recovery environment, using the following procedure.

First, the Mac must be booted to the Recovery environment. This can be from the Recovery volume on the Mac or Apple’s Internet Recovery. Once there, select the Restore from Time Machine Backup option.

Once the Restore from Time Machine assistant launches, click Continue to select the startup drive with the snapshot you need to restore from.

Once the desired snapshot is selected, the prompts can be followed to restore the snapshot.

As part of the restore process, the startup drive is erased and the contents of the snapshot copied to the newly-erased drive.

Once the restore process is completed, the Mac is automatically restarted.

Following the restart, the Mac’s startup drive will be back to the state it was in as of the snapshot’s creation.

If the Mac’s startup drive is encrypted, the snapshots taken of the Mac’s startup drive will also be encrypted. To unlock the encryption protecting the snapshots, two additional steps must be taken as part of the restore process.

First, if an encrypted drive is selected as the restore source, the Continue button is replaced with an Unlock… button.

Once the Unlock… button is clicked, a password prompt will be displayed. This password can be the password of any of the FileVault-enabled accounts on this Mac.

An important thing to know is that only FileVault-enabled accounts’ passwords will be accepted by the password prompt. Personal recovery keys or institutional recovery keys cannot be used to unlock a restore source.

After providing the password, the Unlock… button will change to the Continue button. This will allow you to select the unlocked drive and proceed with the restore process.

The other additional step will be at the Restoring window, where a password prompt will be displayed prior to erasing the drive. This password can be the password of any of the FileVault-enabled accounts on this Mac. This step authorizes the snapshot to be unlocked and restore its contents to the startup drive.

If restoring an encrypted drive from a snapshot, the restore process will also include restoring the encryption state. This capability helps ensure the security of the encrypted startup drive is maintained. It also may save time because the drive does not have to be decrypted or re-encrypted.

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.

There are two ways to remediate this issue, with varying levels of performance impact:

• Update to macOS 10.14.5 and later: Little to no performance impact
• Disable hyper-threading processing support: Medium to high performance impact

Mitigation with little to no performance impact 

Apple and other vendors have provided a way to help guard against exploitation of these vulnerabilities via JavaScript or website-hosted malware by updating web browsers.

• Apple: Updated Safari 12.1.1 as part of the macOS 10.14.5 update
• Google: Will disable hyperthreading as part of Chrome 75 (expected release on or around June 4th, 2019)
• Mozilla: Will apply Apple’s recommended mitigation as part of Firefox 67 and Firefox Extended Support Release 60.7 (expected release on May 21st, 2019)

Mitigation with medium to high performance impact

Apple has included the option to enable full mitigation as part of the following updates:

macOS Mojave 10.14.5
Security Update 2019-003 High Sierra
Security Update 2019-003 Sierra

Full mitigation involves the following:

• Booting to macOS Recovery
• Running commands to disable hyper-threading processing

Once hyper-threading processing is disabled, the Mac will have full protection from the identified MDS vulnerabilities. Please see below for the procedure:

1. Boot to macOS Recovery

2. Open Terminal.

3. Enter the following command and press Return:

nvram boot-args="cwae=2"

4. Enter the following command and press Return:

nvram SMTDisable=%01

5. Run the following command and press Return:

nvram -xp

6. Verify the following values show up:

7. Restart the Mac.

Once the Mac has been restarted, the hyper-threading processing support will be disabled. To verify this, use the following procedure:

1. Under the Apple menu, select About this Mac

2. Click the System Report button.

3. Select Hardware.

4. Check to see if Hyper-Threading Technology is listed as Enabled or Disabled

Enabled: Hyper-threading processing support is enabled

Disabled: Hyper-threading processing support is disabled

This status can also be checked using the command below:

/usr/sbin/system_profiler SPHardwareDataType | /usr/bin/awk '/Hyper-Threading Technology: / { print $3 }'

You can re-enable hyper-threading processing support by resetting NVRAM. For more information on how to reset NVRAM, please see the Apple KBase article linked below:

https://support.apple.com/HT204063

For more information about MDS and Apple’s steps to mitigate it, please see the Apple KBase articles linked below:

About the security content of macOS Mojave 10.14.5, Security Update 2019-003 High Sierra, Security Update 2019-003 Sierra: https://support.apple.com/HT210119

About the security content of Safari 12.1.1: https://support.apple.com/HT210123

Additional mitigations for speculative execution vulnerabilities in Intel CPUs: https://support.apple.com/HT210107

How to enable full mitigation for Microarchitectural Data Sampling (MDS) vulnerabilities: https://support.apple.com/HT210108

Note: The following Mac models may receive the right security updates, but aren’t able to support the fixes and mitigation. The reason is that Intel has not provided microcode updates for these models:

• MacBook (13-inch, Late 2009)
• MacBook (13-inch, Mid 2010)
• MacBook Air (13-inch, Late 2010)
• MacBook Air (11-inch, Late 2010)
• MacBook Pro (17-inch, Mid 2010)
• MacBook Pro (15-inch, Mid 2010)
• MacBook Pro (13-inch, Mid 2010)
• iMac (21.5-inch, Late 2009)
• iMac (27-inch, Late 2009)
• iMac (21.5-inch, Mid 2010)
• iMac (27-inch, Mid 2010)
• Mac mini (Mid 2010)
• Mac Pro (Late 2010)

As part of the release of AutoPkg 1.1, a new-recipe feature was added to help with recipe creation.

It will create a generic recipe file with the following keys added:

• Description
• Identifier
• Input
• MinimumVersion (by default, MinimumVersion will be set for AutoPkg 1.0)
• Process

Under the Process keys, there are additional keys created by default:

• Arguments
• Processor

As an example, here’s the recipe file which is created when the following command is run:

autopkg new-recipe ~/Desktop/MyGreatApplication.download.recipe

For more details, please see below the jump.

Additional options include the following:

• –identifier
• –parent-identifier

These options allow you to define what identifier you want to set for the recipe, along with the identifier of a parent recipe. As an example, let’s set com.github.autopkg.pkg.MyGreatApplication as the identifier for a new AutoPkg .pkg recipe. To set up a new recipe using that identifier, you could run the following command:

autopkg new-recipe --identifier com.github.autopkg.pkg.MyGreatApplication ~/Desktop/MyGreatApplication.pkg.recipe

That would create a recipe with com.github.autopkg.pkg.MyGreatApplication set as the Identifier key’s value.

To include a parent recipe as part of the recipe creation process, you can use the following command to specify both the identifier you want to set for the recipe and the identifier of the parent recipe:

autopkg new-recipe --identifier com.github.autopkg.pkg.MyGreatApplication --parent-identifier com.github.autopkg.download.MyGreatApplication ~/Desktop/MyGreatApplication.pkg.recipe

That would create a recipe with com.github.autopkg.pkg.MyGreatApplication set as the Identifier key’s value and com.github.autopkg.download.MyGreatApplication set as the ParentRecipe key’s value.

As part of my preparation for next week’s WWDC conference, I’ve been working on ways to build virtual machines using VMware Fusion for testing. In previous years, I have used NetBoot-based solutions to help me with this process. With NetBoot going away though, I’ve started using bootstrappr as my replacement deployment tool.

Bootstrappr is designed to install packages and scripts, but in my case I’m having it install only one package: a firstboot package created by First Boot Package Install Generator.app. The firstboot package in turn installs a set of installer packages to configure the VM and install the software I want. For more details, please see below the jump.

Downloading bootstrappr

To download the bootstrappr files, use the following procedure:

1. Go to https://github.com/munki/bootstrappr
2. Click on the Clone or download button.

3. Click on the Download ZIP button.

Preparing a firstboot package

For details on how to prepare a firstboot package using First Boot Package Install Generator.app, please see the following blogpost:

https://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

For this example, I’ll be using a firstboot package named First Boot Package Install.pkg.

Configuring bootstrappr for deployment

1. In the downloaded bootstrappr files, locate the bootstrap directory.

2. Inside the bootstrap directory, add the First Boot Package Install.pkg installer package to the packages directory.

3. Run the make_dmg.sh script in the downloaded bootstrappr files to create a disk image with all of the bootstrappr files inside.

Running bootstrappr

On my own network, I’ve been using bootstrappr’s option of mounting a disk image which is hosted on a web server. This is described as Scenario #2: Disk image via HTTP in the bootstrappr usage scenarios. This allows me to centrally host the disk image and use it when building multiple VMs. However, for next week’s conference, I won’t have access to the web server which hosts the disk image. Instead, I’ll be taking the bootstrappr disk image with me and using a process similar to that described below to set up my VMs.

Converting the bootstrappr disk image to a VMware VMDK file

• Pre-requisites: VMware Fusion

1. Double-click the bootstrappr disk image to mount it.

2. Run the following command to get the disk image’s disk identifier:

diskutil list

3. Locate the identifier for the whole mounted disk image. For this example, it’s /dev/disk2

4. Run the commands below to copy the contents of the disk image to a .VMDK file:

First:

"/Applications/VMware Fusion.app/Contents/Library/vmware-rawdiskCreator" print /dev/disk_id_here

For this example, the command will look like this:

"/Applications/VMware Fusion.app/Contents/Library/vmware-rawdiskCreator" print /dev/disk2

Second:

"/Applications/VMware Fusion.app/Contents/Library/vmware-rawdiskCreator" create /dev/disk_id_here fullDevice /path/to/tempfile lsilogic

For this example, the command will look like this:

"/Applications/VMware Fusion.app/Contents/Library/vmware-rawdiskCreator" create /dev/disk2 fullDevice /Users/username/bootstrapr-staging lsilogic

Third:

"/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager" -r /path/to/tempfile.vmdk -t 0 /path/to/filename.vmdk

For this example, the command will look like this:

"/Applications/VMware Fusion.app/Contents/Library/vmware-vdiskmanager" -r /Users/username/bootstrapr-staging.vmdk -t 0 /Users/username/bootstrap.vmdk

The output of running these commands should look like this:

Once the VMDK file is built, attach it to a VM by using the process described in the link below:

Add an Existing Virtual Hard Disk: https://pubs.vmware.com/fusion-7/topic/com.vmware.fusion.help.doc/GUID-4B3FC5A0-E4A5-4C1B-9F0C-9536628CF4DB.html

Once the VMDK is ready and attached, use the procedure below to boot and configure a VM with an unconfigured copy of macOS installed:

1. Boot to Recovery

2. Launch Terminal

3. Run the following command:

/Volumes/bootstrap/run

4. Select the volume to install on (in this example, the volume is named Macintosh HD.)

The firstboot package included in the disk image is installed.

5. Once installation is completed, select the option to restart.

On restart, the First Boot Package Install workflow is able to suppress the Apple Setup Assistant and run its assigned installation tasks.

This week, I’m out in San Jose, California as an attendee of Apple’s WWDC 2019 conference. As part of this, I’m taking notes during the labs and sessions. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes to Apple’s developer forums rather than to here.

To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts with my notes. It’s available via the link below:

https://forums.developer.apple.com/message/362911

As part of the information published at WWDC 2019 by Apple, the following KBase article has been released:

Requirements for trusted certificates in iOS 13 and macOS 10.15: https://support.apple.com/HT210176

This KBase article describes how Apple is implementing new security requirements for TLS server certificates. These certificates are used by servers to encrypt communication between Apple devices and those servers, to make sure that all communication between the servers and those devices is protected.

• Certificate key sizes must be 2048-bit or greater
• SHA-2 must be used for the certificate signing
• DNS hostname of the server must be listed in a Subject Alternative Name (SAN) certificate extension in addition to being listed in the Common Name field of the certificate.

Also, all TLS certificates issued after July 1, 2019 must meet these additional requirements:

• Must be valid for 825 days (27 months) or less
• Must contain the following Object Identifier in the ExtendedKeyUsage extension: id-kp-serverAuth

What happens if you use iOS 13 or macOS Catalina to try to connect to servers with TLS certificates which don’t meet these standards? The connection will fail because the OS will reject the certificate as being invalid. This may result in a web browser not connecting, an app crashing or some other undesired behavior.

As part of testing iOS 13 and macOS 10.15 ahead of their release dates, I strongly recommend testing the various services used at your workplace to make sure that the TLS certificates used by the services of your company, school or institution are able to pass these requirements. Otherwise, you may find some unfortunate surprises on Release Day this fall.