Currently this is what we are giving to our HD folks to do when users have this issue:

• dscl . -list /Users GeneratedUID | grep putusernamehere | awk '{print $2}'
• Copy users UUID and paste into next command
• sudo diskutil apfs changePassphrase disk1s1 -user replacewithUUID
• You will need to put in the users old password and then put in the new password (should match what they use for the domain)

Obviously this will only work if the drive is formatted for APFS and if the user remembers the current FV password they are using.

I had this issue with a user on a touchbar model yesterday. What worked to get the FV password back in sync was literally just assigning a profile picture on the users account under users and groups in system preferences. I found this fix about a month ago when I couldn't get a users FV account to pop on the login screen. The user was enabled in FV and I tried a bunch of steps from removing/re-adding to FV, pram, turning off FV and re-enabling, etc. The only thing that worked was changing the profile picture and I've been using this workaround whenever I see problems like this and its been working thus far. This isnt the exact post but does talk about this fix: https://www.jamf.com/jamf-nation/discussions/25692/high-sierra-10-13-encrypted-users-not-showing-at-filevault-login-screen

Been seeing success with running these commands:

sudo sysadminctl interactive -secureTokenStatus username
sudo sysadminctl interactive -secureTokenOn username -password –
sudo diskutil apfs updatePreboot /

I just started seeing this issue as well. It doesn't seem to be random for us. Our users change their AD passwords through a webpage, which is fine. Their login password updates once they are connected to the network and log back in.

The preboot password or FV encryption password (that I'm assuming is tied to secure token) does not update to the latest password. In short, that means that the old password is being used when the computer is rebooted. Manual intervention is required to get that to update. I've used a combination of the troubleshooting solutions mentioned here, but what is the actual cause of this issue?

All of the computers I've had this problem on are running High Sierra 10.13.6.

@rcarey I just ran those commands and it worked! Thanks!

macOS Mojave and JAMF Pro 10.8
Adding to this post, I am working with a client where the AD accounts lock at the end of 90 days if the password is not reset. Once this happens and the macOS users get the password reset from the AD admin, not only does the keychain need to be updated but the FileVault secure token password will always be the old password unless there is intervention. I have been using fdesetup to remove and re add the user to filevault or using diskutil apfs changePassphrase command to change the password. Has anyone automated this process? Also even once manually changing the password I noticed when the screen is locked from inactivity is still the old password as well. Has anyone seen this?

I just finished putting together a script to have users fix the FV2 issue from Self Service. I cut and modified a couple things on JAMF Nation from @dennisnardi (THANK YOU!). It's a bit wonky and I have yet to get the guy in here I need to try it on but the prompts and results seem to be what I am looking for. We don't have a lot of users with this issue so I didn't clean mine up much.

I've not seen the locked screen issue myself. Maybe nuking the keychain or PW change through NoMAD would help.

#!/bin/sh
curUser=$(/usr/bin/stat -f%Su /dev/console)

## Get the desired user's account
echo "Prompting ${curUser} for the desired user to fix password mismatch for FV2."
Newuser="$(/usr/bin/osascript -e 'Tell current application to display dialog "Please enter your username:" default answer "" with title "Filevault Password Sync" with text buttons {"Ok"} default button 1 ' -e 'text returned of result')"

## Get the desired user's password
echo "Prompting ${curUser} for the password for desired user to fix password mismatch for FV2."
NewuserPass="$(/usr/bin/osascript -e 'Tell current application to display dialog "Please enter your current email password:" default answer "" with title "Filevault Password Sync" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

JAMFHELPER="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"

RESULT=`"$JAMFHELPER" -windowType utility -title "Filevault Password Sync" -description "You will now be asked to input your current email password in the following box." -button1 "OK"`

## Sets current user with a secure token so it can be enabled for FV2. This requires GUI authentication from the local account but can be run from any account as if secure token admin credentials are entered
sudo sysadminctl interactive -secureTokenOn $Newuser -password $NewuserPass

## Updates preboot with the new password that has been set.
sudo diskutil apfs updatePreboot /

@walts.9 , I have also just (in the last week) started seeing issues with AD users and what appear to be password sync issues with FV2 and AD mobile accounts - two users and counting in the last 24 hours. I fear a widespread epidemic.

Related question for the whole group: when this occurs, does the SecureToken for your user show up as ENABLED or DISABLED? In both cases, my users' accounts, which were working fine for more than 90 days and survived previous AD password changes, were DISABLED. this is the first time I've seen SecureTokens appear to have been Revoked somehow. would love to hear from others about this.

@millersys_seth I can't speak to High Sierra and earlier, but there's definitely a more pronounced issue in Mojave if your user has their password reset outside of System Preferences or a tool like Nomad. The most common examples would be a reset via web portal or Active Directory. On prior versions of macOS it was expected behavior for the Keychain or FileVault to not get updated until the user rebooted (or another method of forcing a sync), but in Mojave the cached password does not get updated. So a user can have the "new" password work in their account/the lock screen/Keychain, but the FileVault password remains the "old" password after a reboot.

Last week there was a big thread in the Mojave channel MacAdmins Slack, apparently this is a known issue on Apple's end but the response was essentially "this might get fixed in 10.15."

As far as secureToken... I've definitely observed an AD user get stripped of secureToken if a policy used the Jamf binary or dscl to change the password. Had to use this in a policy to consistently retain secureToken on an AD user:

sysadminctl -adminUser $adminUserHere -adminPassword $adminPasswordHere -resetPasswordFor $userToBeReset -newPassword $newPasswordHere

@rcarey , that worked for me as well. Thank you! You just saved me a ton of work with one of our executives laptops!

Thanks @ncottle . Your script has saved us a ton of time

I just used the recovery to reset the password and now it's synced

@rmonteroc I was heading this same direction but getting hit with "Authentication server could not be contacted" while in Recovery HD (10.14.3). I went into macOS and unbound the test machine and still got the error. Had no idea dsconfigad worked in Recovery. Did you experience anything like this?

@ncottle Thanks for the info. The script works great, but in my environment, I have to enter the local admin account to get it to work properly. This means that I can't have users just run from Self Service, since they don't have this password. Any ideas?

Just curious if anyone has had success with @ncottle 's script in self service. It works great when I run it from terminal, but have when I run it from self service, it just executes with no prompts.

!/bin/sh

curUser=$(/usr/bin/stat -f%Su /dev/console)

Get the desired user's account

echo "Prompting ${curUser} for the desired user to fix password mismatch for FV2."
Newuser="$(/usr/bin/osascript -e 'Tell current application to display dialog "Please enter your username:" default answer "" with title "Filevault Password Sync" with text buttons {"Ok"} default button 1 ' -e 'text returned of result')"

Get the desired user's password

echo "Prompting ${curUser} for the password for desired user to fix password mismatch for FV2."
NewuserPass="$(/usr/bin/osascript -e 'Tell current application to display dialog "Please enter your current email password:" default answer "" with title "Filevault Password Sync" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

JAMFHELPER="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"

RESULT="$JAMFHELPER" -windowType utility -title "Filevault Password Sync" -description "You will now be asked to input your current email password in the following box." -button1 "OK"

Sets current user with a secure token so it can be enabled for FV2. This requires GUI authentication from the local account but can be run from any account as if secure token admin credentials are entered

sudo sysadminctl interactive -secureTokenOn $Newuser -password $NewuserPass

Updates preboot with the new password that has been set.

sudo diskutil apfs updatePreboot /

@walts.9 The only way we deploy is through Self Service. I'll try and remember to take a look on Monday and see how I have it set up. @benk234 Have you tried removing some of the user input and populating the info via the script. Obviously not anything in clear text but something along those lines? Been a little bit since I've messed with what I did. Recently switched to a new group so my brain is a little overloaded right now. Please feel free to message me. I'm happy to help in any way I can.

@walts.9 Here’s a version I have in Self Service with user prompts

I'm now feeling very hopeful that macOS 10.14.4 will resolve this issue. 😉

@true[robby] have you tested a 10.14.4 beta or has Apple support indicated it will be fixed with that release?

Testing in 10.14.4 beta and it's looking good!

My findings show that after the 10.14.4 update, a subsequent password change via System Preferences while on domain will sync up all three passwords (local account, keychain and FileVault) and stays synced while off domain. ✅✅✅

I'm even finding that if the user once again changes their password somewhere other than their machine (a web interface like OneLogin), the local password syncs and stays synced when off domain. ✅ Upon next reboot, if the user chooses to Update Keychain it will sync up keychain and FileVault. ✅✅

So we're back to behavior on earlier versions.

@ true[robby] thanks for posting.

What if the user has forgotten their previous password and enters a recovery key at FileVault and for keychain has to create a new one? Is the account password and FV password still out of sync on next reboot?

What happened for me is not exactly the same as per OP.

• MBP 2016(Mac OS Mojave 10.14.3)
• Joined to Windows AD
• Everything seems fine until a password change is done
• After password is changed, user can only login using new password when connected to the Office Network
• When outside office network, user needs to use previous password
• Updating Keychain when prompted does not fix this issue
• Only solution was to unbind and rebind again,

I have just tested the latest Mojave Developer Beta update and confirmed this issue is fixed.
Passwords will now sync across as soon as the mac gets connected to domain network.

@MatG After using the recovery key to unlock the volume we are presented with our normal logon screen. I think this behavior is different. Before, when using the recovery key the user is given a pop-up at the logon screen to change their password. But now, the volume can be unlocked but the user still needs to know the existing password to log in. So we don't get far enough to be able to answer your keychain question.

Can I ask what version number of the Mojave Developer Beta update fixed the issue for you?

I think it was beta 2 or 3. Cant remember. Its now beta 6 so I'd guess release next week.