APFS Archives - Mr. Macintosh

How To Regenerate a New FileVault 2 Personal Recovery Key (PRK)

MrMacintosh.com - How To regenerate a FileVault 2 Personal Recovery Key. — How To reissue a FileVault 2 Personal Recovery Key

It’s good practice to have a backup of important things in your life. You wouldn’t only keep one set of keys to your house or car. The same goes for your FV2 Encrypted Mac. The FileVault Personal Recovery Key is your backup key to your Mac. If your account password is not working or if you can’t remember the password, the Recovery Key will be the only way to get to your data.

Two Different Types of FileVault 2 Recovery Keys

When encrypting your Mac, you have two different types recovery key options.

(PRK) Personal Recovery Key – Every Mac has a unique Recovery Key.
(IRK) Institutional Recovery Key – One Recovery Key for every Mac

While it may be convenient to have one key for every Mac, having a Institutional Recovery Key is like having a Master Key to an Apartment Complex. If that key is stolen or lost, the bad guy has a key to every single apartment unit. The same thing goes for the (IRK) if one user has the key, it’s known for every single Mac.

The PRK is the way to go, as each Mac has a unique key.

I previously wrote about how to use the PRK to recover data from a Mac using Target Disk Mode.

https://mrmacintosh.com/filevault-2-target-disk-mode-unlock-using-the-personal-recovery-key/

Why Would Would I Need to Change my Personal Recovery Key?

Here are a few reasons why you might need to reissue or generate a new FileVault 2 Personal Recovery Key.

1. The Computer Record was deleted from your MDM.
2. The MDM Recovery Key Entry is corrupted.
3. The Recovery Key is not working.
4. The PRK is given to a user and you want to cycle and protect it.
5. The PRK user is missing, or the ? mark is not showing at FV2 login.
6. If you need to reenroll a Mac into a different MDM.

A good example of #2 is when Jamf Pro 10.7.1 screwed up the recovery key display in every computer record. This defect was fixed in Jamf Pro 10.10.

https://www.jamf.com/jamf-nation/discussions/31910/filevault-2-personal-recovery-key-issue

Reissue the FileVault 2 Recovery Key with FV2 Enabled Username and Password

To generate a new FileVault 2 Personal Recovery Key we will be using the fdesetup binary.

First you can check to see if your Mac is using a PRK or IRK.

sudo fdesetup haspersonalrecoverykey = true or false

sudo fdesetup hasinstitutionalrecoverykey= true or false

Now we can change the recovery key using username and password.

sudo fdesetup changerecovery -personal

Enter the user name:mrmacintosh

Enter the password for user 'mrmacintosh':

New personal recovery key = 'Z5V7-K464-PEVT-09OX-Q2EW-8FO8'

This works for 10.13 – 10.15

Reissue the FileVault 2 Recovery Key using the Current Personal Recovery Key (PRK)

Staring in 10.14, you can now use the current Personal Recovery Key to generate a new PRK.

You will be using the UUID of the Personal Recovery User and the current PRK as the password.

Find the UUID of the Personal Recovery Key User

sudo fdesetup list -extended

ESCROW UUID TYPE USER

0A1BCDC3-49BD-4E00-B741-813E143AD1E2 OS User mrmacintosh

EBC6C064-0000-11AA-AA11-00306543ECAC Personal Recovery Record

Note: The UUID of the Personal Recovery User is the same very every FV2 Encrypted Mac.

Let’s change it.

sudo fdesetup changerecovery -personal

Enter the user name:EBC6C064-0000-11AA-AA11-00306543ECAC

Enter the password for user 'EBC6C064-0000-11AA-AA11-00306543ECAC':

New personal recovery key = 'Z5V7-K464-PEVT-09OX-Q2EW-8FO8'

For the password field, all we need to do is enter in the current FV2 PRK.

NOTE: If you want to send the Recovery Key to Jamf Pro, you need to run Recon twice.

Running commands are great for 1 or 2 Macs, but what if I have to fix more than that?

The guys at HCS Technology Group wrote up an excellent article showing us how to create a policy for this. The policy will search for all Macs that do not have a valid recovery key and will remediate with a script kicked off by a Jamf Policy.

https://hcsonline.com/images/PDFs/Jamf_Recovery_key_Filevault.pdf

Credits

Hat Tip goes out to Johan McGwire aka yohan on #MacAdmins. He brought up the 2nd way to reissue the Personal Recovery Key with the current PRK. Johan the expert behind the following projects. Check them out!

Also HCS Technology Group, I can’t say enough about these guys. They have written some of the best MacAdmins guides available today!

Get the full list HCS White Papers, visit this link.

http://hcsonline.com/support/white-papers.

Follow them on Twitter! https://twitter.com/HCSTechnology

10.15.3 Combo & Security Updates are not Creating Backup Snapshots

MrMacintosh.com - 10.15.3 Combo & Security Updates no Longer Creating Restore Snapshots + 10.15.3 Update Deletes All Previous tmutil localsnapshots — 10.15.3 Combo & Security Updates are no Longer Creating Restore Snapshots + 10.15.3 Update Deletes All Previous tmutil localsnapshots /

The 10.15.3 Combo & Security Update Automatic Backup Snapshots are no Longer Created.

UPDATE: 5/15/20 – A few questions came up on MacAdmins Slack about the current state of Automatic Snapshots today. To clarify, the following is now true.

Automatic Update Snapshots are no longer automatically created during the 10.15.3+ Combo but ARE for 10.14 & 10.13 Security Updates
The 10.15.3+ Combo Update REMOVES previous manual localsnapshots.
10.14 & 10.13 Security Updates do NOT remove previous manual snapshots.
Automatic Snapshots were never taken during an OS Upgrade.

UPDATE: 4/24/20 – Apple has removed the “Restore from snapshot” feature description from apple.com/macos/catalina/features! This means that the feature is no longer available in Catalina. I really hope Apple can fix this.

The APFS Update Automatic Snapshot was a new option offered when Apple released APFS in macOS 10.13 High Sierra. If you were worried about something going wrong after installing a macOS Combo or Security update, you could always fall back to a backup taken right before the update. The process was automatic and was performed by the Combo Update and Security Update Installer. To restore, all you needed to do is, boot to the recovery partition and restore to a tmutil localsnapshot / right before the update.

NOTE: you only have 24 hours to restore or the snapshot is automatically deleted.

Apple explains how this works below.

MrMacintosh.com - Apple.com Restore from Snapshot. — apple.com/macos/catalina/features

Automatic Update Backup Snapshots are no Longer Working.

Something happened in the latest set of Apple updates released on January 28th. The Automatic Backup Snapshots are no longer working!!! At first, I thought it only happened on the 10.15.3 Combo update. I then checked the 2020-001 Security Update on High Sierra and it’s not working either!

I found this out while I was writing another article on Catalina Logs. I built a 10.15.2 device and updated it to 10.15.3. I booted to recovery to restore the from the automatic snapshot only to find that it was missing!

Manual tmutil localsnapshots are deleted during the 10.15.3 Update installation!

Ok, what would happen if I created a manual snapshot before the update? If the automatic snapshot is not working, I could get by with just creating one right before I install the 10.15.3 combo update.

MrMacintosh.com - Manual tmutil localsnapshot / created before the 10.15.3 combo update. — Manual tmutil localsnapshot / created before the 10.15.3 combo update.

After installing the 10.15.3 Combo Update, I booted back into Recovery only to find that the manual tmutil localsnapshot / that I created was gone!!!

What should happen after the update.

Below is what you should see if you booted to recovery after a combo or security update. The below example is a backup snapshot taken by the 10.14.2 Combo Update.

MrMacintosh.com - automatic update backup localsnapshot — This is what you should see if you booted to recovery after a combo or security update. (within 24 hours after the update install)

Let’s take a look at the logs

What do the logs say? Well first I would like to see what a successful snapshot says. Searching the install.log, I found exactly what I was looking for.

MrMacintosh.com - 10.14 Automatic Snapshot. — That is just what I’m looking for. The automatic snapshot was taken right before the installation.

Let’s take a closer look to see what’s happening during the 10.15.3 combo update install. Looking at the install.log again, I found this entry.

MrMacintosh.com - 10.15.3 purges localsnapshots — The 10.15.3 Combo Update purging snapshots.

There it is, the Installer is purging available snapshots on /Volumes/Macintosh HD. The 10.15.3 install.log does not contain any of the log items like the one from 10.14.

The good news is that the (2020-001) 10.14 and 10.13 Security Update installers do NOT purge your manual tmutil localsnapshots.

What’s going on, is this a bug?

I am not totally sure what’s going on here, if I had to guess this a bug. I wanted to let you know about this. The last thing you want to do is rely on that automatic backup snapshot only to find out it was never created.

Either way, please let Apple know about this!

If you have any questions or comments please Contact Me or leave a note below. Thanks!

Apple releases long-awaited SecureToken documentation

We have been waiting for SecureToken Documentation since 10.13 Beta 1 and the introduction of APFS. I go into this in my previous article 3 Undocumented macOS Mojave 10.14 Enterprise Fixes. I talk about what SecureToken is and how we need SecureToken Documentation. The sysadminctl binary still doesn’t have a man page. You will see why, once you read on how Apple recommends that you use fdesetup instead of sysadminctl.

sysadminctl documentation — sysadminctl’s only documentation.

Documentation Please!

Many MacAdmins have called on Apple to give us some information explaining how the system works. Since 10.13 Beta 1 we have been left to fumble around and figure all this out on our own. The other problem was, that from 10.13.0 to 10.14.4 the system had many bugs and has even changed many times. It was really hard to keep up much less understand what was going on.

Enter macOS Deployment Reference “Use of SecureToken”

Now that we have the document, what does it say? Does it shed any light on the situation? In a word no… but it finally puts everything into words for new MacAdmins. Most of the information posted was already known and hashed out by experienced MacAdmins who have spent hours testing SecureToken. We will be able to share this document when anyone has questions about how SecureToken works.

Any key takeaways from the document?

1. If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.

This statement is a little confusing yet could also be true depending on your setup. For example you can use MDM/DEP with the setting “Skip Account Creation” then bind to a directory service with a policy to enable FV2 on login. In this situation the management account/admin user is not granted a SecureToken. The first directory user to login will get a SecureToken by enabling FV2 . This is the perfect scenario, as you don’t need a tech waiting around to enter in the admin username and password for the first user logging in.

Editor’s Note: for the above situation. If you do not have a policy to enable FV2 on login the mobile account will not get a SecureToken. I never tested out this scenario. Big thanks for the clarification from TravellingTechGuy who put together a really nice SecureToken flow chart. You can find that chart here.

2. “Important: In macOS 10.13.5 or later when using a directory service and mobile accounts, users won’t be prompted about SecureToken during first login if there are no SecureToken accounts already available on the Mac. See below for additional information.”

In 10.13.3-10.13.4 directory users were prompted with this message even if the first user was logging in. You had to hit bypass to get that first login SecureToken. Now as this message states, if you logged in as the first user you are not prompted. The document also goes over how you can disable this pop up.

Seeing this note reminds me of an additional change to the SecureToken Pop up message in 10.14.4. When you log in the SecureToken message will not come up if the SecureToken account already on the system is not an admin. The point of this change is that the SecureToken user has to be an admin to enable the new user logging in. If the standard SecureToken user is not an admin don’t even bother to show the message because you would be unable to add the new user to FileVault anyway.

3. ” Managing which users can unlock a FileVault encrypted volume should generally be done using the command-line tool fdesetup. However, you can use the command-line tool sysadminctl specifically to modify SecureToken status for user accounts on the Mac. This should be done with caution and only when necessary.“

It’s interesting how Apple actually recommends using fdesetup instead of sysadminctl. The reason I say that is that we all use sysadminctl to create accounts and mange SecureToken.

The problem with using fdesetup to add an additional user to FileVault is, the account does not show the securetoken as enabled. Instead you should really should use diskutil apfs listCryptoUsers / or sudo fdesetup list -extended to get a proper list of enabled CryptoUsers. I am just pointing out that we are still having non consistent results when checking the FV2 status of a user when using sysadminctl.

You can try this yourself in 10.13.6 (17G6029) & 10.14.4 (18E226)

sudo fdesetup add -user adminuser -usertoadd mrmacintosh

sudo fdesetup list

adminuser,C26BADFD-6763-093E-8U73-3K13EN938AL3

mrmacintosh,93K18AE6-H187-497C-928F-3K13EN163AL3

sysadminctl -secureTokenStatus mrmacintosh

sysadminctl Secure token is DISABLED for user mrmacintosh

You can still unlock the volume in this condition and will report properly using the above command diskutil apfs listCryptoUsers / or sudo fdesetup list -extended.

Conclusion

In this article I point out a few things that still need some work. With that said, this document is a move by Apple to give us the needed documentation that we have asked for. We are also seeing more information in beta patch notes and Enterprise Content when a combo update is released. I hope this trend continues!

Apple Link to Device And Data Security Use of SecureToken.

https://help.apple.com/deployment/macos/#/apd8faa99948

If you are outside the US you can use this link

https://help.apple.com/deployment/macos/?lang=en#/apd8faa99948

Shout out to Rich Trouton ‏@rtrouton for the late night heads up on this.

Also to Neil Martin @neilmartin83 for noticing that the link does not work outside the US!

SecureToken Documentation

10.14.4 update fixes AD Mobile Account/FileVault password change sync

Before we get started I’m am going to talk a little bit about how macOS and Active Directory work together. I will also go into some history behind the built-in AD Connector. In the end, I will explain the current problems we are having with Active Directory Mobile Account password syncing and how Apple fixed the issue.

If your company or school uses Active Directory, you most likely use Mobile Accounts. To get Mobile Accounts to work you first have to bind the Mac to Active Directory, once bound the Mac is now trusted. You can now log in with any Active Directory user and access to Global Groups, Kerberos and Directory Contacts.

Sounds great right? It was!

Once you log in, the system caches your AD account to the local directory. If you then disconnect the Mac from the network you can still log and continue to work. When the time comes to change your AD password you could change it on a 2nd Mac, a Windows device or even a Web Portal.

How did the AD password change work?

If you changed your password on the Mac it would first check if any password requirements are set at the domain level. If you passed the requirements the password would be immediately changed in Active Directory. The password would then change at the local offline level of your Mac. If you changed your password outside the Mac (Web Portal etc..) the system would receive the password change the next time you connected the Mac to the network and logged in. You would then be promoted to Update or create a new Login Keychain.

Active Directory & FileVault 2

The AD password change system changed in 10.7 with the addition of FileVault 2. Now when you changed your password an extra step had to be performed. Once the password was changed in AD it would then change the locally cached password and then had to sync that password down to your FV2 account. When you turned on your Mac, you could then use the same password as your AD account to unlock the volume and start booting the system. The AD password sync system worked pretty well from 10.7 all the way up to 10.12 Sierra. Users would sometimes have issues here and there when the Mac dropped off the domain but usually a rebind and would save the day.

10.13, APFS and SecureToken

Apple introduced the next-generation file system called APFS (Apple File System). We first got to test it out in 10.12 Sierra in beta form. APFS was standard for all SSD drive installations on 10.13 High Sierra installs. You could still opt out with commands and spinning hard drives would still use HFS. When 10.14 arrived APFS was standard across all hard drives. The introduction of APFS brought an added undocumented security feature called SecureToken. If you wanted to enable FileVault 2 you had to have SecureToken enabled for said account. You could no longer you use the PRK (Personal Recovery Key) or even a local admin to add extra users to unlock the volume like you could with HFS. You have to grant the 2nd user a SecureToken before they could become an authorized CryptoUser. To get the token in the first place you had to be the first user logging into macOS at the SetupAssistant.

10.13 was the start of syncing issues for Mobile Accounts.

The main problem with this new system was that the SecureToken system was not tested. Mobile account users, in particular, had nothing but problems with this new system. From 10.13.0-10.13.3 AD Mobile Account password syncing to FV2 flat out did not work. During this time frame we had multiple high priority tickets in with Apple Enterprise Support. When 10.13.4 hit Apple finally fixed the issue and password syncing started to somewhat work again. I say somewhat because everyone still reported issues but at least it worked SOME of the time now. 10.13 still had problems when you changed the password off the Mac.

Enough of the history lesson, get to the 10.14 problem!

Once 10.14 hit we were hoping that the problems we had on 10.13 Mobile Accounts would fixed. Unfortunately, we were wrong, way wrong. The problem worse when 10.14.0 released. How could it be worse than 10.13 and how did miss the problem in 10.14 beta? On 10.13 as I mentioned above we had to deal with of Mobile Account syncing of FV2 passwords. The user would change the password outside the system and it would not make it down to FV2. The good thing is we actually have fix for this!

The following instructions will change or Sync the password for the CryptoUser account that belongs to the AD user. This will only work if the user KNOWS the old password since the command will prompt for the current password.

1. diskutil apfs list (Grab the disk label for Volume Macintosh HD usually disk1s1)
2. sudo fdesetup list -extended (grab the UUID of the OS USER) You can also use diskutil apfs listCryptoUsers /
3. diskutil apfs changePassphrase disk1s1 -user UUIDhere (add in the UUID of the OS USER from the pevious command and put it in UUIDHere.

That’s cool, but you still haven’t told us why is the situation worse in 10.14?

The local cached offline password is never changed!

The problem is the issue is undetectable UNTIL the user attempts to authenticate OFF the network. When they try the current password it will NOT work. They will then have to call the helpdesk, who then changes the AD password making the situation even worse. This is the situation for 10.14.3 and below.

When connected to the network = Current AD Password works!
When Disconnected from the network = ONLY previous password works.
FV2 password = Previous Password.

Things get even more annoying is if the user actually uses the old password to authentiate the Screen Saver while offline. The system will accept the password but then immediately prompt the user to unlock the Login Keychain. This is due to the keychain being set to the current AD password. You would be in a never-ending keychain password cycle.

Do you have a fix for the offline sync issue?

The good news is we do, as long as you have a SecureToken enabled Admin user. All you need to do is turn off SecureToken and then turn it back on. Something in this system will then sync the offline cached password. Shout out to @annemacro on MacAdmins Slack for figuring this out!

sudo sysadminctl -secureTokenOff useraccount -password – -adminUser adminuseraccount -adminPassword –
sudo sysadminctl -secureTokenOn useraccount -password – -adminUser adminuseraccount -adminPassword –

Now that 10.14.4 is out the password sync mechanism now working. As long as you update systems to 10.14.4 before users change their AD password they will not have this issue going forward. I have not had the chance to actually test the 10.14.4 update on a system that is already out of sync. The good news is that even if it doesn’t fix the issue when it is already happening you now have the tools to fix it yourself. The next time the user changes their password they will not experience the issue.

Why did this take so long to fix?

The answer to this question is pretty simple. Everyone missed the bug from beta 1 all the way through into 10.14.0. I performed hours and hours of testing in beta. I was so concerned about that the FV2 password did not sync that I did not even think to test the offline password. Even worse, neither did anyone else including Apple. It was not until around 10.14.2 when I had an enterprise ticket in with Apple and finally got a response.

“This bug will not be fixed until the next release of macOS”

When I read the reply to this support ticket I was in complete shock. Are you going to tell me that we are going to flat out have a NON FUNCTIONING MOBILE ACCOUNT SYSTEM FOR THE ENTIRE 10.14 RELEASE? I could not believe it. The Apple Enterprise Support Engineer I was working with also agreed and he was fantastic to work with and helped work through the issue with me. At this point what else would a #MacAdmin do but RANT in MacAdmins Slack!!! The best way to do this is to document and explain the issue to others. You can then rally other MacAdmins to file Enterprise tickets or Radars. This will draw attention to the issue and generate heat inside Apple Enterprise Support. In the end that’s exactly what happened. We were not the only company that Used Mobile accounts. Those same companies let Apple know that we needed a fix ASAP. Apple realized this was important and fixed this issue for us in 10.14.4. (Thank you Apple!)

Where does that leave Mobile Accounts?

Before 10.13 Mobile Accounts worked very well. We had thousands of Macs connected to AD utilizing Mobile accounts and did not have any issues. Once 10.13 hit things started to go downhill. The problem is, it seems like Apple is not spending enough time on Mobile Accounts. The MacAdmins community has started to realize this and starting at the end of 2017 and into 2018. This began what I call “The great Mobile Account exodus to Local Accounts”. NoMAD and Enterprise Connect make using local accounts while still having the ability to use AD resources easy. Mobile Accounts still serves it’s purpose but it seems the writing is on the wall.

Thanks

If you stuck around to read the entire article I really do appreciate it. If you are at WWDC 2019 or JNUC 2019 I will buy you a beer or non-alcoholic beverage. Just mention coupon code #ISURVIVEDMOBILEACCOUNS.

I hope to write many more articles like this in the future. Over the past 15 years MacAdmins have helped me get to where I am today. I hope I can give back to the community and help the next generation of MacAdmins rise through the ranks! Drop me a note at com gmail mrmacintoshblog