Active Directory password changes maybe not syncing to FileVault on High Sierra

New Contributor III

I've had 3 cases of mobile account users on High Sierra (10.13.3) changing their Active Directory password then finding the password doesn't get updated for FileVault. I've had no such trouble on Sierra. The updated password works in macOS once FileVault is unlocked by another user. The only workaround we've found in to remove the user from FileVault and add them back again.

Has anyone else seen this, know if it's fixed in 10.13.4, or have any other workarounds?


New Contributor III

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.


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/"

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 /

New Contributor III

@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.

Valued Contributor

New Contributor III

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

New Contributor II

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

New Contributor III

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. :white_heavy_check_mark::white_heavy_check_mark::white_heavy_check_mark:

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. :white_heavy_check_mark: Upon next reboot, if the user chooses to Update Keychain it will sync up keychain and FileVault. :white_heavy_check_mark::white_heavy_check_mark:

So we're back to behavior on earlier versions.

Contributor III

@ 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?

New Contributor

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.

New Contributor III

@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.

New Contributor

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

Contributor III

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

Contributor III

I just posted an article about the history of the 10.13 & 10.14 syncing issue. I included some fixes that you can use if you still have some accounts that are still out of sync.

New Contributor III

FWIW. I just had a troublesome 10.14.5 machine that wouldn't sync the FV password to the locally cached or domain password. Nuking the keychain fixed the issue.

I tried a battery of solutions until I finally thought of this so I hope it helps someone.

New Contributor

Thank you @sshort

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

Using this from a command prompt fixed our issue of an AD user not able to login after password was changed elsewhere. No FieVault in use.


New Contributor III

We are seeing this issue on random machines on different versions of Mojave. Its very frustrating. Anyone confirm if this is still an issue in Catalina? We have it blocked for a bit for testing purposes. Or, does anyone have a non-interactive version of the above command that can be scheduled?

New Contributor II

@mgorton It is still an issue in Catalina. In fact, I came here looking for an explanation and a possible solution.

We are rolling out FileVault enabled laptops running 10.15.2 and have begun experiencing the same symptoms reported in this thread: User changes AD password, often through a web portal (sometimes over WiFi, sometimes over ethernet), and then they are unable to log in at the preboot screen. The old password is usually able to unlock the volume, but the new AD password otherwise works for authenticating against other AD bound services. it will also work at the system login screen is the user logs out.

I have been able to correct this, as others have, by using the recovery key. Once the recovery key is provided, the user is prompted for their network password and then the passwords are synched.

I haven't yet tried some of the other fixes recommended here, but will do so first chance I get. Thanks to all for sharing your experiences and expertise.

Contributor III

@mheffernan If you change the password off the Mac through a web portal all you are changing int the AD account password, therefore FileVault password will not change. If you change the password on the Mac it will update your AD account password and the FileVault password.

However if you do change the password through a web portal then on boot as you say use the old password, then you probably get prompted again to login into your account, then a Keychain box then what is meant to happen is macOS is meant to sync the account password down to FV, but in Catalina 10.15.1,2 and now 3 this I believe is broken.

Contributor III

Here is my self service script to resolve this filevault issue if the user changes their password in a way other than System Prefs/ Nomad .
This does require you have a local admin account on the computer and that you pass the local admin user name and pass as variables $4 and $5.
I did not have great luck with the update preboot command that @ncottle used (though I haven't tried the script posted here) so I wrote a script doing the same thing with FDE setup awhile back.

#! /bin/bash

#Found commands at

userName=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )

fdesetup remove -user $userName

if [[ "$userName" == "adminName" ]] || [[ "$userName" == "HardCodedLocalAdminName" ]]; then
    echo "Admin user is logged in."
    exit 1
    dialog="Do Not run this tool when logged in as Admin! Exiting!"
    cmd="Tell app "System Events" to display dialog "$dialog""
    /usr/bin/osascript -e "$cmd"

dscacheutil -q user -a name $userName

sleep 1

echo "prompting user for Account Password"
tell application "System Events"
set the answer to text returned of (display dialog "Enter your Current Account Password:" default answer "" with hidden answer buttons {"Continue"} default button 1)
end tell

expect -c "
spawn fdesetup add -usertoadd $userName
expect "Enter the primary user name:"
send ${adminName}
expect "Enter the password for the user '$adminName':"
send ${adminPass}
expect "Enter the password for the added user '$userName':"
send ${userPass}

fdeList=`fdesetup list | grep $userName`

if [[ "$fdeList" == *"$userName"* ]] ; then
    echo "$userName Filevault Password Updated successfully"
    dialog="$userName Filevault Password Updated successfully"
    cmd="Tell app "System Events" to display dialog "$dialog""
    /usr/bin/osascript -e "$cmd"
    exit 0
    echo "Adding $userName to FV2 Failed"
    dialog="Adding $userName to FV2 Failed"
    cmd="Tell app "System Events" to display dialog "$dialog""
    /usr/bin/osascript -e "$cmd"
    exit 1


I usually use diskutil apfs changepassphrase, though I haven't made a script of it yet. If it works it would alleviate the need to pass an admin password in clear text.