Skip to main content

- 2020 MBP 13" 4x Thunderbolt ports

- Active Directory bound

- Enterprise Connect for password sync

- FileVault 2 configured (via mobileconfig profile)

1. User was prompted to update AD password

2. User set new password with Enterprise Connect, as instructed.

3. FileVault unlock screen does not recognize new password, only the recovery key (escrowed in Jamf), and the user has immediately forgotten their old password, so I can't test if that would still have worked.

4. Thinking this is some kind of AD/Keychain disconnect, I nuke the user's keychain.

5. This doesn't resolve the issue, so I unbind & rebind to AD.

6. This doesn't resolve the issue, so I create an exception and remove the FV mobileconfig profile, and manually turn off/decrypt FileVault, reboot, log in, remove the exception in Jamf Pro and re-enable FV. A new recovery key is escrowed.

7. User's current password still doesn't unlock the volume on reboot. New recovery key works.

8. I exchange the laptop to get the user up to speed, and bring home the offender for further analysis, slightly panicking that password resets are broken and we are going to have to deal with some kind of persistent fleet-wide issue that requires hands-on the entire fleet.

9. After sitting overnight in the office, the device is cured! I come back the next day and it accepts the user's current AD password to unlock the volume.

...WHYYYYYYY

 

I reach out to Apple, get escalated 5 times and finally get a "that's weird, bro!"

I try to replicate the issue on another laptop by resetting a password via Enterprise Connect on an AD-bound laptop. No problem. Filevault picks up on the change with no issue and lets me decrypt with the new password.

So, on the one hand, stoked that this seems not to happen any time a password is synced.

On the other.... wtf happened with this laptop?

 

TLDR: FileVault is weird and scary, does anyone know what kind of log files I should/could be looking at?

Console > Log Reports shows me nothing of value.

@johntgeck Are you really still using Enterprise Connect (EC)? Or are you actually using Kerberos Single Sign-on introduced in macOS Catalina but still referring to it as EC? I ask because we did see occasional instances of the problem you describe where a newly changed password was not recognized by macOS when using EC with macOS Catalina, but since making the change to Kerberos SSO as of macOS Big Sur that hasn't been a problem. 

@johntgeck Are you really still using Enterprise Connect (EC)? Or are you actually using Kerberos Single Sign-on introduced in macOS Catalina but still referring to it as EC? I ask because we did see occasional instances of the problem you describe where a newly changed password was not recognized by macOS when using EC with macOS Catalina, but since making the change to Kerberos SSO as of macOS Big Sur that hasn't been a problem. 


We're still using EC because we have AD bind and mobile accounts, not local, so Apple KSSO won't sync passwords for us.

For anyone who stumbles across this, I've seen this one other time so far, and I was able to resolve it based on the steps in this thread. Basically, it had to do with the relationship between AD -> MacOS -> Filevault and how all three can basically have different passwords that need syncing. Since this was a mobile AD account the bind had gone stale so even though the user is not allowed to update their password via MacOS, it had lost its ability to sync with AD and update through Enterprise Connect (the way our users are currently educated to do so).

1. Re-bind to AD.

2. Update password via Enterprise Connect.

3. Use the diskutil apfs changePassphrase command in terminal to sync the old password with the new. This method does require that the user knows their original password. Please see the thread linked above for add'l details on how this works and what information you'll need.

Terms & ConditionsCookie settingsAccessibility statement