Apple Enterprise Connect will fix password sync issues with FV, macOS and AD.

We bind our Macs to AD and use NoMAD for password management.

In your case, if removing the securetoken doesn't help, you could try "fdesetup remove -user username_goes_here" and then after a restart, add the user back to filevault.

We no longer bind because of this reason. I'm currently moving all the machines that are bound to NoMAD and unbind the machine. Our Helpdesk team is very happy that we've moved this direction as they don't have as many calls about the passwords not in sync. We still have some Macs that are bound but are making progress on getting all of them converted to NoMAD.

@B-35405 We had them come out for a demo and it only would fix our issues if the password was changed on the computer itself which we do not allow.

@iRyan23 Thanks I will try that next time I see it! @Merkley Do you have them reset their passwords though the OS? NoMAD works for me testing it but I was told it would likely not be receiving any updates in the future and we'd have to move to Jamf Connect which has not worked for us in a proof of concept. If i could feel comfortable NoMAD was sticking around and would be active for newer OS systems and had support I would certainly consider it!

Enterprise Connect won't help if the user changes password anywhere else.

@Over9000 I have them reset their passwords through NoMAD. If they do end up changing their passwords outside of NoMAD, like though OWA or in AD, NoMAD notifies them that their password was changed elsewhere. I don't have them change their password through System Preferences because NoMAD doesn't pick up on that change. From what I've heard with NoMAD is the open-source one will still be developed along side Jamf Connect. The Jamf Connect version is the NoMAD Pro previously and doesn't connect to an on-prem AD. It's primarily for cloud directory services, like Azure AD and Okta.

With that said though, Catalina is bringing in a new password extension based on Enterprise Connect. So I'm looking forward to see how that'll work in my environment.

@Merkley wrote:

With that said though, Catalina is bringing in a new password extension based on Enterprise Connect. So I'm looking forward to see how that'll work in my environment.

Its about time! #bustinApplesChops

@donmontalvo it's in one of the WWDC videos that available to the public. It was the "What's new with managing apple devices." Starts around 35 minutes talking about the new SSO pieces that includes the new password extension.

@Markley ahh...edited. :D

Link to video where Apple discusses this.

@iRyan23 Thanks!

I hope this new Catalina AD password sync feature will work better for what we need!

Are you guys still having AD FV2 password syncing issues? This was fixed in 10.14.4.

https://mrmacintosh.com/macos-mojave-10-14-4-update-fixes-ad-mobile-account-filevault-password-change-sync-issue

@ClassicII I can double check with the technicians but as far as I'm aware, we're still using this solution for every password change. Our users reset their passwords through a web portal, not through the OS so the fix you have on the link you provided is what our users have to do:

sudo sysadminctl -secureTokenOff useraccount -password – -adminUser adminuseraccount -adminPassword – sudo sysadminctl -secureTokenOn useraccount -password – -adminUser adminuseraccount -adminPassword –

I have a script in self service that prompts the user for the admin credentials (the technician is present to enter it), then the user's credentials and it will execute the above commands to fix it. I thought the 10.14.4 would stop this issue but we still have it for users running the latest OS. Thankfully we don't have a large Mojave base yet we still only support Sierra for reasons like this.

Yeah, this is still broken in 10.14.6. Appears to exist on Catalina as well.

@mgorton and it will be forever broken in 10.14.6. Fingers crossed in 10.15.3 or 10.15.4 or 10.15.5....or 10.15.6...it won't be.

Yeah, just discovered its broken in 10.15.2 so far. This is pretty unfortunate. If Apple can't handle this type of basic functionality, we're probably going to have to use Nomad to sync passwords or something similar.

@mgorton As far as I know Nomad isn't able to sync to Filevault.

The password will sync to the system login but not filevault. The problem is that filevault lives in it's own little preboot world/volume. If you allow authentication pass through from filevault(so say 1 login, not 2 to get into the computer) supposedly the password sync issue is fixed then.

@mgorton I doubt this issue will ever be fixed in a software update. The solution is to change the password on the computer via Nomad or System preferences instead of changing it elsewhere.

I've also added this as a policy to Self Service to allow it to be fixed after the fact. It just asks the user for their current password and will remove them and re-add them to filevault with the correct password.

Edit: The formatting is weird on this site. The fdeList= variable should have backticks around "fdesetup list | grep $userName"

#! /bin/bash

https://www.jamf.com/jamf-nation/discussions/26608/adding-user-to-filevault-using-fdesetup-and-recovery-key

adminName=$4 adminPass=$5 userName=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' ) fdesetup remove -user $userName if [[ "$userName" == "adminName" ]] ; 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" fi echo "prompting user for Account Password" userPass=$(/usr/bin/osascript<<END tell application "System Events" activate 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 END) 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} expect" 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 else 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 fi

So we are running into a similar issue as listed in the OP. I have a use that has 2 FleVaulted LAptops both joined to AD, he changes his password on one of them, thru System Preferances and FileVault updates fine.

He logs into the second laptop, updates the keychain but FileVault doesn't update, i thought updating the keychains would be enougth...

WOuld the script above need to be ran to fix this issue for us?

@szultzie Updating the Keychain password will not affect filevault in anyway.
Running the script above as the user (i put it into a Self Service policy) should fix the issue.

Hope is coming soon with this issue. I promise

@Over9000 Could you share the script you use for the secure token?

I have one as well but is very simple and Im worried that the password is stored locally in history