@mm2270 Do you mind sharing your script or give some insight on how you picked up a password change?

I would like to account for passwords changing outside of users and groups.

Hi @kwatt29 I apologize for the confusion. I kind of misread your post. We aren't picking up a password change and doing anything automatically. That would be pretty difficult to do, if not impossible.
What I put together instead was a Self Service driven policy that runs a script. The script does several things.

1. Because we are all Active Directory accounts, it first checks to see if the logged in account is AD based.
   It also checks to make sure the Mac is joined properly to AD and can communicate with the primary domain controller.




2. It checks to see that a) FileVault is enabled and b) the logged in account is currently enabled for FileVault (uses fdesetup to check)




3. Once it passes these tests, it uses cocoaDialog to show a dialog explaining what will happen (general terms)
   It then asks them for their FileVault password. This is the one that they use to unlock the Mac, and is usually the now old password.




4. In the background, it uses this password to create a temporary "tempfv2" account on the Mac. This account has no user home folder, but has a valid record in local directory services.




5. It then uses the user's valid FV2 password to add this account to the authorized FileVault list. We do this because our Macs are mostly single use systems, so the primary user is the only one with an enabled FV2 account in almost all cases. We also don't enable the management account for FileVault.




6. Once that is verified to have worked, it will ask the user (again using cocoaDialog) for their current AD password. The one that they need to use at the regular username/password login screen, or to unlock the screen, etc.




7. It captures this, then removes the user's account from the FV2 list, then re-adds it back in, but using their current password as it adds it back in. it uses the previous "tempfv2" account to do this, since it is now the only FileVault enabled account on the Mac.




8. Once that is confirmed to have worked, it removes the tempfv2 account, and cleans up any leftover files and such and tells the user it was successful. It encourages them to reboot immediately to be sure they can log in past FV2 with their current password.

This whole process gets the password back in sync since its really removing them, then re-adding them to FileVault with their current password.
During all of this, there are functions in the script that will handle any errors, like if the user entered a wrong password for FileVault in the first step. It re-runs the function asking them for their password if that's the case, but I only give them 3 tries. If after 3 attempts its still failing, it stops and tells them to open a support case to get more direct assistance, since at that point we can assume something is wrong or the client isn't reading the instructions.

All of this requires that the client know their old password and their new one. If they don't know one or the other, they can't really use this process. This is mostly because there's no way to pull the Mac's Recovery key from the API or some other scripted method. Otherwise, I could use the Recovery key to add/remove accounts.

I hope the above helps explain how we are doing it. Its admittedly a hack, but we've had something like a hundred clients go through this process when their passwords got out of sync, with very few failures. The failures I've seen are usually either user error, or, in some cases, the password sync finally happened and the client wasn't aware of it because they hadn't rebooted in a while.

I don't know if I can post the script here as is. I would need to sanitize it a bit, because there are some specific items to our environment, like the domain controller check and so on.

Thanks for the thorough explanation @mm2270. I'm interested in how you could use the filevault recovery key to add and remove users to FV2. I'm not seeing anything on the man page for fdesetup. I'll open up another discuss and stop spamming this one.

@easyedc thanks for pointing out logging out and logging back in. This resolved the issue on a 10.11.2 machine today.

(mm2270) did you ever get a chance to clean up that script, suitable for sharing on here? we're having the exact same issue and it sounds like your script is exactly what we need.

Thanks)

@kericson Did you get anywhere with the Air-Watch issue?

Seeing the same issue, when a Mac is enrolled in air-watch, something breaks the sync between filevault and login password.

It seems to be either temporary, or permanent. My main laptop is now permanently out of sync.

We've seen it on 3 of about 7 installs, so loathed to deploy Air-Watch for Mac OS X if this is going to happen a lot.

We have local admin account users currently, no AD, no complexity, just filevault, airwatch, and current Mac OS X. Also did Air-Watch reproduce this for you?

We have a second passcode related issue with Air-Watch on Mac OS X, where a passcode profile overrides the screensaver grace period specified in Security and Privacy profile. This is a real nasty, because it default back to 5 minutes. So you think your user's screensaver has immediately locked their laptop, but because you tweaked the passcode policy since you deployed the Security and Privacy profile you now have 5 minutes to walk up to and own their laptop.

Any pointers to details technical documentation on these issues very welcome.

@mike.goddard Hi, no, I never did get around to doing that, but I can look at that at some point within the next week or so.
There are certainly other scripts similar to mine that do something along the same lines in case you need something in a hurry. I don't have any links handy, but I recall that @stevewood has a similar script around if I'm not mistaken?
Barring that, you can wait for me to post it here if its not a very time sensitive issue.

Sorry @mike.goddard but the script I have is for moving domains. We moved from a local AD domain to a corporate wide AD domain and I have a script that did the move. It basically removed the machine from OD (we had a few bound to our OD) or from AD if it were bound to an old AD, then it bound to the new one. The final step was to add the user back to FV2 since their UID would have changed. You can find the script here:

Move AD Domain

To fix an out of sync FV password, you would need to remove the user from FV and then re-add them. You would need to have an admin user already in FV to do this, or have access to the FV key for that machine, because once you remove them you have no way of adding them unless you have the key or another user to use.

Ah, yes, now I remember. Similar principal, but different use case entirely. Thanks for chiming in @stevewood!

We see this behavior ALL THE TIME. None of our Macs are bound to AD. Local accounts only.
We see this behavior on all macOS Versions from 10.10.x up to 10.14.x.
We also set the following CIS password controls.

• Number of max failed logins before account lockout - CIS Benchmark 5.2.1 (Scored)


• 5 min lockout (in seconds)


• Required password length - CIS Benchmark 5.2.2 (Scored)


• Number of required lower case letters in password - CIS Benchmark 5.2.3 (Not Scored) & 5.2.6 (Not Scored)


• Number of required upper case letters in password - CIS Benchmark 5.2.3 (Not Scored) & 5.2.6 (Not Scored)


• Number of numeric characters in password - CIS Benchmark 5.2.4 (Not Scored)


• Number of non-alphanumeric characters in password - CIS Benchmark 5.2.5 (Not Scored)


• Number of days until password expiration - CIS Benchmark 5.2.7 (Scored)


• Remember last used passwords - CIS Benchmark 5.2.8 (Scored)

Other odd behavior we see... User gets locked out after changing password, they need to wait 5 minutes - this IS expected... BUT... it also locks out the ability to use the FileVault Recovery Key during that 5 minute period.

Any thoughts? Anyone? Bueller? Bueller?

@cainehorr with respect to the password being out of sync there are some good tips here:
Jamfnation: AD PW changes not syncing to FV on HS

TLDR: What to do when user password is out of sync with their FV2 password -- when they know their old and current passwords.

sudo fdesetup list | grep $USER   #where $user is the name of the user out of sync

It will return

USER,27E97FDA-252E-1D28-97E2-E11278DB2D21

then copy the long UUID and enter:

diskutil apfs changePassphrase disk1s1 -user 27E97FDA-252E-1D28-97E2-E11278DB2D21

You will be prompted for the old password and the current password.

@joshuaaclark this worked great for me in Big Sur - only issue is somehow the FV2 password screen will still not pass through the regular login screen even though the passwords are identical now. Any idea how I can get them to sync up again? User is currently authenticating with the same credentials twice now every time they reboot. Has anyone scripted this process yet?

@JMenacker Is com.apple.loginwindow set to DisableFDEAtoLogin?

@JMenacker - Please follow this article (https://www.jamf.com/jamf-nation/discussions/38652/a-reliable-fix-for-filevault-2-password-sync-issue) and let me know if you are able to fix the password sync issue.

Seems like it took about 24 hours to sync but, this morning the customer confirmed that the steps we followed in @joshuaaclark's post above from 5/20/2020 did ultimately work. Patience is a virtue, I guess! Thanks to all who replied so quickly, it is much appreciated. I feel like this would be really slick in a script from someone who has a talent for that - not my wheelhouse, unfortunately.