Archive

Archive for the ‘Apple File System’ Category

Mounting Time Machine local snapshots as read-only volumes

February 23, 2019 Leave a comment

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.

Screen Shot 2019 02 23 at 10 44 17 AM

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.

Screen Shot 2019 02 23 at 10 59 43 AM

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.

Screen Shot 2019 02 23 at 11 45 51 AM

For more details, please see below the jump.

Read more…

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

February 10, 2019 5 comments

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.

Read more…

Unable to enable FileVault on macOS Mojave

February 8, 2019 2 comments

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.

Read more…

T2, FileVault and brute force attack protection

November 1, 2018 1 comment

Apple recently released an overview document for its new T2 chip, which includes how the new T2 chip-equipped Macs have new protections against brute force attacks. This protection only applies if FileVault is enabled and is similar in concept to how iOS devices set with passcodes are protected against brute force attacks.

On iOS, if an incorrect passcode is entered more than five times, a one minute delay is set.

Img 58462d7da9d03 477x600

After the sixth try, the delay is now five minutes and the delays get longer from there until the device has the 10th wrong passcode entered and the device wipes.

Screen Shot 2018 11 01 at 4 31 50 PM

On Apple iOS devices with a Secure Enclave, those delays are enforced by the Secure Enclave processor. Similarly, the T2 chip-equipped Macs also have a Secure Enclave processor which is managing access attempts and introducing delays.

For Macs with Secure Enclave, the enforcement looks like this:

  • 30 unlock attempts via using the password at the login window or target disk mode
  • 10 unlock attempts via using the password in Recovery Mode
  • 30 unlock attempts for each enabled FileVault recovery mechanism
    • iCloud recovery
    • FileVault personal recovery key
    • FileVault institutional recovery key

The maximum number of unlock attempts is 90, regardless of the mix of methods used. After 90 attempts, the Secure Enclave processor will no longer process any requests to do the following:

  • Unlock the volume
  • Decrypt the volume
  • Verify the password / recovery key

Delays are also imposed on macOS between attempts.

Screen Shot 2018 11 01 at 8 40 50 AM

So what happens after 90 attempts? Does the Mac lock forever and become a paperweight?

After checking with AppleCare Enterprise, the answer is that the Mac will not be a paperweight, but that the Mac’s boot drive will need to be erased before it can be used again. This approach helps make sure that the Mac is still usable, but also ensures that the encrypted data stored on the boot drive is no longer recoverable.

For more information about brute force protection for encrypted iOS and macOS devices, I recommend checking out Apple’s currently available white papers:

Reclaiming drive space by thinning Apple File System snapshot backups

April 7, 2018 14 comments

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

Screen Shot 2018 04 07 at 2 04 39 PM

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

Read more…

Slides from the “Managing FileVault 2 on macOS High Sierra” Session at MacAD UK 2018 Conference

February 21, 2018 4 comments

For those who wanted a copy of my FileVault 2 management talk at MacAD UK 2018, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MacADUK2018pdf

Keynote – http://tinyurl.com/MacADUK2018key

Hat tip to the attendee who brought to my attention that fdesetup sync is not supported on encrypted APFS boot drives. I’ve now updated the slides to reflect that it works on macOS High Sierra for HFS+ drives only.

HFS+

Screen Shot 2018 02 21 at 12 54 13 PM

APFS

Screen Shot 2018 02 21 at 1 04 16 PM

Secure Token and FileVault on Apple File System

January 20, 2018 38 comments

As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account 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. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.

Users and groups preference pane only user gets secure token automatically

Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.

For the consumer user, this usually takes the following form:

  1. Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
  2. The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.

However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.

Filevault preference pane account without secure token cannot manage filevault


Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:


Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:

  1. Administrative rights
  2. Secure Token

For more details, please see below the jump.

Read more…

%d bloggers like this: