Filevault not syncing AD password

[swapple]

We just had a round of passwords expire and now some of our users use their old AD password to get past the FV2 login screen, then use their newly reset AD password to get into the OS. How do we get the passwords to sync back up? I saw the apple solution to use a sudo touch command to delete the cache and let it rebuild, but that has not worked for us yet. Any other tips or trick on getting them back in sync?

[jason_bracy]

1. If the user changes their AD password at the Mac login Window or in the Users & Groups control panel, then this will also set their FV and keychain password.
2. If they change their password using another method (like an intranet website or PC) then the passwords will be out of sync. In order to resent them you need to enable the "Synchronize login keychain password with account" preference in Keychain Access. to do this I have Casper push out the following script:

#!/bin/bash 

defaults write com.apple.keychainaccess SyncLoginPassword -bool true

killall cfprefsd

Once you do this, when they log into their account if the Mac detects that the login keychain password is different than the AD password it will present a dialog asking for the old password.

[ryan_s]

If the AD password was updated on the users' Macs (locally from SysPrefs) this is good news! If it was not, you will have keychain issues each time a password is reset utilizing any other method. This will also cause FV password to be out-of-sync as you described.

In our environment, when we see FV being out-of-sync with the login keychain it usually takes one boot to the user-account (along with an unlock of the login.keychain, which should be automatic on loading the user account). Once this occurs, the FV password should sync with your login keychain ... if not (i.e. you maybe had a broken keychain or had to remove it), the quickest workaround is to remove the user from FV

sudo fdesetup remove -user username

...and then re-add them after. This is helpful in the event a user does remember their old password (which seems to be quite frequently for whatever reason)

Hope this helps!

[mm2270]

Welcome to the FileVault Password Out-of-sync Club, and enjoy your exclusive club benefits!
OK, in all seriousness, we still see this issue occurring on our Macs. However, since around 10.10.4 and up, it has calmed down quite a bit. We have/had a ticket open with Apple enterprise support on this, and though they have not stated this was addressed, something in the later versions of Yosemite was changed that is helping address this, at least for us. I only know that when it occurs, you can see specific entries in the system.log stating that the FDESupport process has failed. I believe FDESupport is what helps keeps the passwords in sync. So that being said, are you experiencing this on older revs of Yosemite, or on Mavericks? If so, any chance you can get them updated to 10.10.5?

As to how we've addressed this prior to the recent OS updates, is with a Self Service policy that uses a bash script with cocoaDialog as the front end for the user interaction.
Essentially when its run, it first does a few checks on the Mac. The Mac must be in range of a DC, meaning it can talk with AD, the account running the policy (logged in user) must be an AD account, and that account already has to be enabled for FileVault, meaning its in the authorized list of accounts that can unlock the Mac.
Once it passes all these checks, it asks the user to enter their old password, the one FileVault is accepting at the boot up screen. It captures this in a variable and then does some background work. It uses their old FV2 working password to create a temporary "tempfv2" account on the Mac. This account has a dscl record and uses the Mac's serial # as its password, but has no home folder. It uses their valid FV2 password to add this account into the authorized FileVault list using a plist file and a fdesetup add -usertoadd -inputplist command.

Once confirmed that worked, it then asks them for their current AD password, the one we want FileVault to use. It then removes the user account from the authorized FV2 list, and finally, tries to add them back in with their new password, using a similar method as above, but uses the newly added tempfv2 account for authorization. If this fails for some reason, it comes back and asks them to re-enter their password again. It will make up to 3 attempts. If it keeps failing, it stops after 3 tries, and alerts them that they need hands on support, since something is not working. In most cases though, this works to add them back in, but using their current AD password.
Once it all works successfully, it removes the tempfv2 account from the FileVault list, and makes sure to clean up the plist files so it doesn't leave anything behind. It does the same cleanup steps if it failed, unless the account was removed and the only account left in FileVault is tempfv2. It leaves this in place since you can't remove the only FileVault enabled account on the Mac. It will complain if you try to.

When it works, it then tells them that they should reboot to confirm they can unlock their Mac at the FV2 login screen as a check to make sure they are all set.

We've had hundreds of our Macs run this policy successfully. Prior to this our only recourse was to decrypt and re-encrypt the Mac, which is a hassle to say the least.

[AVmcclint]

When this happens to us, the user will:

1. login to the filevault login using their old password
2. they are prompted for their network login since the old one no longer works
3. after they login using their current network credentials, they are usually prompted with keychain password alerts. No matter what they input, it never seems to make the alerts go away
4. I launch Keychain Access and then click on the padlock to change the state until it tries to unlock it.
5. at this point it usually asks to update the password and I have then input their old password into the "current password" box and enter their current password into the "new password" box
6. after that's successfully done, I then drop into Terminal and run

   sudo fdesetup sync

7. I wait a few seconds just to give it time to do what ever it does, then I reboot and have the user login from the beginning with their most current network login.

[mm2270]

sudo fdesetup sync does not sync up AD passwords to FileVault. See Rich Trouton's article on this.
https://derflounder.wordpress.com/2014/12/21/fdesetup-sync-fdesetups-misunderstood-command/
If that's working for you, its purely coincidence.

[jason_bracy]

To be honest I think most of these issues have been mitigated in 10.10.4 and later. My experience is that once the user logs into the Mac with their correct password, then FV resets itself (btw, @AVmcclint the sudo fdesetup sync command only removes FV users that are no longer in AD. It does not do anything with passwords)

The issue that we had is the delay in login vs AD becoming available. i.e. if the user changed their password on a different computer while the Mac was off, then booting the Mac and entering their old FV password would allow the user to login using the cached credentials due to the fact that when it got to the login screen network accounts were not available yet. However if the user changed their password on a different computer while logged into the Mac, and then restarted, then while the Mac had synced with AD, the login process had not yet synced FV, so the user would need to use their old password for FV and would then be presented with the login window where they enter their new password. They will also then be presented with the keychain reset dialog.

I have never needed to remove and re-add a user to FV, but then maybe I am just lucky :-)

[chrispetersmark]

We see this issue off and on in our org, especially when users' update their password from somewhere other than their local Mac (Windows VM, web portal, helpdesk reset, etc.) - many of the steps outlined above will work just fine.

Are you using Kerberos tickets to track password changes? If so, friendly plug for ADPassMon which makes this process MUCH easier for us.

[hcgtexas]

@mm2270 Would you still happen to have that FV2 reset script?

I'm having the same issue, and no other FV2 accounts to use as backup. That script looks like it will be a lifesaver.

[swapple]

Rich is the leading expert on this, his site is full of great scripts! https://derflounder.wordpress.com/?s=filevault

[bearzooka]

After a lot of testing, debugging, and looking for ways to script this in a user-friendly manner, we came up with an AppleScript that follows the suggested steps in order to fix the Secure Token of the affected user, thus putting the passwords back-in-sync.
FVPassword-Sync
Some variables need to be adjusted to fit each specific environment, and once it's proven to work in your devices, it can be deployed via Self Service and easily followed by most users.

[drakkn]

Hi Bearzooka,

I am setting up this script but am really not sure if I am overthinking the domain path variable. I'm not running a forest with multiple domains. So just the domain name again? Or an ldap type path?

[bearzooka]

Well @drakkn, each company has its specific settings, but I can recommend using the interactive mode of dscl in Terminal, and from there use ls and cd so you can get your path right.

[Mhomar]

@mm2270 Would you still happen to have that FV2 reset script?

I'm having the same issue and am at a loss here and currently in the FileVault Password Out-of-sync Club

Thanks Mike

[avogel]

I also had the same problem that the password was not changed automatically after changing in FileVault.

For this I had written a small script for the users. Users can change the password manually in Self Service. Maybe it will help someone.

#!/bin/sh


##########################################################################
# Shellscript       :   Allows you to change the FileVault password
# Autor             :   Andreas Vogel, 31.10.2019   
##########################################################################


## variables

user=$(stat -f '%u %Su' /dev/console | cut -d ' ' -f 2)
UUID=$(dscl . -read /Users/$user GeneratedUID | awk '{print $2}')

askPassphrase () {
    osascript <<EOF - 2>/dev/null
tell application "SystemUIServer"
    activate
    text returned of (display dialog "$1" default answer "" with hidden answer)
end tell
EOF
}

jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
jamf="/usr/local/bin/jamf"


## Icon
FileVaultIcon="/Library/Application Support/JAMF/SmallFileVaultIcon.png"
ErrorIcon="/Library/Application Support/JAMF/France_road_sign_A14.svg.png"
SuccessfulIcon="/Library/Application Support/JAMF/ok-1976099_640.png"

######################################################################################################################################

## Messages
Message="
This program synchronizes the Windows password and the FileVault password.
Only proceed if the Filevault password does not match the current Windows password."

FailedPwMessage="
The verification of the password failed, please re-enter the new password."

FailedPwMessageAgain="
The input does not match again. The program is ended."

FailedChange="
The password could not be changed. Try again. If the problem persists, contact the Mac_IT."

SuccessfulChange="
Your password has been changed successfully."

######################################################################################################################################

## Query whether the user really wants to change the password. 
HELPER=$("$jamfHelper" -windowType utility -icon "$FileVaultIcon" -title "Change FileVault password" -description "$Message" -button1 "OK" -button2 "Cancel" -cancelButton "2" -defaultButton 2)
            echo "Jamf Helper Exit Code: $HELPER"

## If the user agrees, the old password and the new password will be requested. 

if [ "$HELPER" == "0" ]
then
        oldPassphrase=$(askPassphrase 'Please enter the old password.') || exit                       
        newPassphrase=$(askPassphrase 'Please enter the current Windows password.') || exit 
        newPassphrase2=$(askPassphrase 'Please enter the current Windows password again.') || exit    


## Check whether the new password matches.
        if [[ $newPassphrase != $newPassphrase2 ]]
        then 

                HELPER=$("$jamfHelper" -windowType utility -icon "$ErrorIcon" -title "Wrong Entry" -description "$FailedPwMessage" -button1 "OK" -defaultButton 1)
                echo "Exit Code: The entry did not match"

                newPassphrase=$(askPassphrase 'Please enter the current Windows password.') || exit 
                newPassphrase2=$(askPassphrase 'Please enter the current Windows password again.') || exit
        fi

## Check again. If the recheck is faulty, the tool is terminated.       
                if [[ $newPassphrase != $newPassphrase2 ]]
                then 

                    HELPER=$("$jamfHelper" -windowType utility -icon "$ErrorIcon" -title "Renewed wrong entry" -description "$FailedPwMessageAgain" -button1 "OK" -defaultButton 1)
                    echo "Exit Code: Die Eingabe war erneut falsch."

                    exit 1          
                fi

## If the tool was not closed, the password is changed.             
                    if diskutil apfs changePassphrase disk1s1 -user $UUID -oldPassphrase $oldPassphrase -newPassphrase $newPassphrase
                    then

                        printf HELPER=$("$jamfHelper" -windowType utility -icon "$SuccessfulIcon" -title "Successful Change" -description "$SuccessfulChange" -button1 "OK" -defaultButton 1)
                        echo "Exit Code: Password has been changed succesfully."

                    else

                        printf HELPER=$("$jamfHelper" -windowType utility -icon "$ErrorIcon" -title "Error" -description "$FailedChange" -button1 "OK" -defaultButton 1)
                        echo "Exit Code: Password could not be changed. Is the old password correct?"
                    fi

fi

exit 0

[Pauileoo7]

worked for me also , anything on use for M1

[bmee]

@avogel Do you know if your script will prompt the user to enter in the admin credential?

[avogel]

@bmee No The script does not request admin privileges. After running the script, the user only needs to enter the current password for FileVault and then confirm the new one and the new one again.

With us, no users have admin privileges.

The script is used to make sure that users have changed the ad password through a different way than through the MacBook.

[roach]

@avogel I have had success with 2 intel machines, but the script failed on a M1 workstation. Have you tested it yet on silicon? 

Script result: Jamf Helper Exit Code: 0
Error changing passphrase for cryptographic user on APFS Volume: The given APFS Volume is not encrypted
Changing passphrase for cryptographic user on APFS Volume disk1s1
HELPER=0Exit Code: Password could not be changed. Is the old password correct?

[dstranathan]

This page below has updated details on ARM M1, M2 Macs. The target disk that is encrypted might be disk3s1 or other (not disk1s1). Change the script to programmatically determine this value rather than using a hard-coded value for the disk.

https://community.jamf.com/t5/jamf-pro/a-reliable-fix-for-filevault-2-password-sync-issue/m-p/234243...