We have an open case for this with Apple. They have a very long set of instructions on how to fix it, and they don't work reliably. I've had some systems where we've had to reimage because sometimes we can't add any user back again after.

Do you use Enterprise Connect?

This has been on again off again issue since FV2 was released, so much so that we are/were at the point of "it's just they way it works". I also think that part of the issue is the KeyChain app not working 100% right all of the time...

C

It has been an issue for a long time, that's true. It's become more complicated with the implementation of APFS and Secure Token requirements.

I did find a weird way around everything to get them synced again, but you have to have a working local account with a secure token that you can added to FileVault remove the FV user having issues and then re-add them back. If you don't have a local secure token enabled user, you can re-create one by deleting the .AppleSetupDone file from /var/db/ and creating a new "first" admin account that gets a secure token. It's a absolute mess, but has worked for me every time.

Apple really needs to fix this issue on their end though. Senior management doesn't really like it when i tell them this is a known Apple issue.

Seems like i've had to say that a lot with High Sierra.

Has anyone seen any improvements with FV password syncing in 10.13.4? I changed my AD password via Users & Groups on my primary Mac, but FV on a different Mac I use just will not sync up at all. I logged in using my old PW to unlock the drive, then used my current password to login. I've let it sit, connected to the network for hours and it still doesn't sync the PW.

We're having the same issue as well. Been trying to raise it with Support but we're not getting a lot of traction, and have gotten some curious responses from Apple Enterprise & EC support. @alexjdale could you share your case number? Would like to draw our team's attention to it.

Have experienced this as well... I noticed the last reply is from 5/5... just wonder if any of you had seen improvements past 10.13.3?

Yes we’ve been getting quite a few cases like that. Suddenly unable to login to the mobile account with any credentials. Haven’t found a solution yet however...

Had to remove and redo the profile account and other times reinstall macOS, or fresh install. I can remove the enabled account from FileVault however cannot add it back.

Also to note, we also have enterprise connect installed and Macs running 10.13.5

Still seeing this, on a pretty random basis. Whats really annoying about it is although the user has a secureToken, we get an authentication error if we try to pass the token to another user. It locks us down where the user can not auth through FV2 and cannot unlock their token to pass it to another user... so we can't add a new FV2 user to remove and re-add their account. So far it's been two rebuilds for us.

Seeing it here too. Mainly on our users with shorter password expiration periods.

Can you guys let me know what the resolution was for this issue?

sudo diskutil apfs changePassphrase disk1s1 -user [uuid]

might change it for you, but you'll need to know the old and new password for the user.

ok thanks

We've been seeing this randomly over the last few months and this:

diskutil apfs updatePreboot /

Seems to do the trick for us at least...

Haven't been able to get this resolved on our end. Will try some of the recommendations here, but also have a ticket open with Apple. Got machines running various versions of 10.13 all the way up to 10.13.6. Only "fix" that has seemed to work for me has been deleting the user and home folder, and rebuilding. Our work around has been to give users their own local admin to log in and then log out to get into their primary user account with their AD credentials.

At the very least, glad to see others experiencing this, because I couldn't find much of anything. Spoke to one person at Apple's Enterprise support who told me that because my "fix" worked, it was THE solution, until I pushed back enough to get him to get someone else involved.

sudo diskutil apfs changePassphrase disk1s1 -user [uuid]

Has been working for me 100% of the time AS LONG AS the user remembers their old password. If they do not then it's been rebuild city.

I am using a Self Service policy to enable FV on HiC, it prompts the user to enter their password when run. In my testing running this policy again and having them enter their new password when prompted works okay, no old password required.

We found that if the user updated their AD password off machine, and the machine was on wifi, the computer password and preboot password did not update. Sometimes the computer password would update, but every time the preboot password did not. Our fix was to have the users open Terminal and su into their account:

su <ad username>

Once they entered their password the computer and preboot passwords were updated with their new AD password.

@hkabik I had to run "diskutil apfs listcryptousers disk1s1" to get the UUID for "Local Open Directory User" but your tip works!

We've had several people come down where their username appears at the encryption login screen, but won't accept the password (new one or old one).
We solve it by logging in with our support account and running the fdesetup command in terminal to remove them, then add them back in.

sudo fdesetup remove -add username

sudo fdesetup add -usertoadd username

We've had success with the FDE commands but seem to have to wait a day to get them added back in. It's really a pain. Will be trying @hkabik solution today I am sure as more people are stopping by.

Tried @hkabik solution. Got the following error: "Error changing passphrase for cryptographic user on APFS Volume : Malformed UUID (-69578)"

Anyone else seeing and error like that?

Did you verify you entered the users UUID correctly? That error occurs when the UUID is not formatted properly. Should look like: 3725AF28-0188-42F3-BB46-64758DED2169

Easiest way to get the user's UUID is

sudo fdesetup list

Gotcha, thanks. That makes sense. I will try again next time. Appreciate the quick response @hkabik .

That command also assumes your Macintosh HD is disk1s1 which it most likely is, in the case it is not simply trade out disk1s1 for your actual identifier.