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

[hessf]

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?

[alexjdale]

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?

[gachowski]

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

[alexjdale]

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.

[nwiseman]

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.

[AVmcclint]

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.

[chris_kemp]

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.

[rmaldon]

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?

[simon_brown]

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

[hkabik]

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.

[macbentosh]

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

[anthonytji]

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

[hkabik]

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.

[anthonytji]

ok thanks

[mbezzo]

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

[rcarey]

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.

[hkabik]

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.

[MrRoboto]

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.

[stevewood]

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.

[zinkotheclown]

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

[JustCallMeAJ]

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

[ncottle]

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.

[ncottle]

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?

[hkabik]

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

[ncottle]

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

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

[afarnsworth]

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.

[narichardson]

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

[rcarey]

Been seeing success with running these commands:

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

[walts_9]

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.

[ssuttle]

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

[chrisbarbieri]

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?

[ncottle]

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 /

[millersys_seth]

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

[sshort]

@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

[jarradyuhas]

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

[rcurran]

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

[rmonteroc]

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

[robby_c137]

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

[benk234]

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