FileVault login and account password out of Sync

[maiksanftenberg]

Hi.
Maybe stupid question but I did not really found something on the web.

We have a little problem from time to time with Account passwords.
Some users that uses there AD account face some problems from time to time that there own password get not synchronised with the FileVault 2 login screen password.

This password is still the old. In most cases where this happen the account password has been rested due different reasons or has been changed outside of OS X (like on a Windows machine).
Even a reboot did not help.

Is there anything that we can do to get the passwords back into sync?

Thanks for your help.

[maiksanftenberg]

I might found the answer on my one by a "mistake" :D.
https://jamfnation.jamfsoftware.com/discussion.html?id=7054

[JPDyson]

This probably has to do with cached credentials; in our experience, performing a live, networked login with the AD account syncs up the FileVault authentication.

[Kyuubi]

This used to happen to us all the time. Is the keychain updated with the new password?

[maiksanftenberg]

Even with networked login the password was not synchronised between the Account and the FileVault did not worked.
But something like this is mentioned here: http://www.cnet.com/news/can-filevault-be-bypassed-with-os-x-password-reset-routines/

[jyergatian]

Hi everyone,

I'm having an issue which I assumed was normal, until a recent JNUG. All machines are running 10.9.5 and bound to AD using a Configuration Profile. Our user passwords expire every 90 days, forcing the user to change them accordingly. So far, every time this occurs, the FileVault pre-boot window doesn't function with the new password. My resolution has been to remove the user with fdesetup and then re-add using System Preferences.

I've done a little homework, and tried many suggestions. This was completed on a test machine. Here are the results.

This occurs in /var/log/opendirectory.log every time the test user logs in.

2015-01-15 16:37:48.188389 PST - Module: FDESupport - Failed to update passphrase for (user UUID)

Attempted the following,

rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/*.efires

Received the following in /var/log/system.log

Jan 15 16:55:30 devicename.local sudo[827]: localadm : TTY=ttys001 ; PWD=/Users/localadm ; USER=root ; COMMAND=/bin/rm /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/Lucida13.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/battery.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/disk_passwordUI.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/flag_picker.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/guest_userUI.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/loginui.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/preferences.efires /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations/unknown_userUI.efires
Jan 15 16:55:35 devicename.local com.apple.kextcache[832]: rebuilding /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations
Jan 15 16:55:35 devicename.local efilogin-helper[833]: targetVolume: /
Jan 15 16:55:39 devicename.local com.apple.kextcache[832]: /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations not cached.
Jan 15 16:55:39 devicename kernel[0]: hfs: mounted Recovery HD on device disk0s3
Jan 15 16:55:39 devicename.local mds[80]: (Normal) Volume: volume:0x7fb70782e000 ********** Bootstrapped Creating a default store:0 SpotLoc:(null) SpotVerLoc:(null) occlude:0 /Volumes/Recovery HD
Jan 15 16:55:39 devicename.local fseventsd[40]: Logging disabled completely for device:1: /Volumes/Recovery HD
Jan 15 16:55:40 devicename.local com.apple.kextcache[832]: Successfully updated disk0s3.
Jan 15 16:55:40 devicename kernel[0]: hfs: unmount initiated on Recovery HD on device disk0s3

Attempted the following,

sudo touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

Received the following in /var/log/system.log

Jan 15 16:52:28 devicename.local com.apple.kextcache[798]: rebuilding /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations
Jan 15 16:52:28 devicename.local efilogin-helper[799]: targetVolume: /
Jan 15 16:52:32 devicename.local com.apple.kextcache[798]: /System/Library/Caches/com.apple.corestorage/EFILoginLocalizations not cached.
Jan 15 16:52:32 devicename kernel[0]: hfs: mounted Recovery HD on device disk0s3
Jan 15 16:52:32 devicename.local mds[80]: (Normal) Volume: volume:0x7fb706004600 ********** Bootstrapped Creating a default store:0 SpotLoc:(null) SpotVerLoc:(null) occlude:0 /Volumes/Recovery HD
Jan 15 16:52:32 devicename.local fseventsd[40]: Logging disabled completely for device:1: /Volumes/Recovery HD
Jan 15 16:52:33 devicename.local com.apple.kextcache[798]: Successfully updated disk0s3.
Jan 15 16:52:33 devicename kernel[0]: hfs: unmount initiated on Recovery HD on device disk0s3

Any help would be greatly appreciated.

[bentoms]

@jyergatian, that actually sounds correct.

If a users password is changed then then need to unlock the Mac using their old password at the FV2 screen.

Once they have logged in & am on the domain, FV2 should update with their new password automagically.

[jyergatian]

@bentoms, Thanks for the input.

Just to clarify, The user is typically resetting their password using the Users & Groups System Preferences Pane or at the standard Login Window when prompted. On my Test machine, I replicated the issue using the same methods and using ADPassMon V2. In all scenarios, the device is connected to the domain and in all scenarios, repeated restarts don't appear to resolve the issue, nor waiting up to 2 hours (longest time tested thus far).

After each successful Login, FDESupport attempts to update the EFI password and presents this error in opendirectory.log:

Module: FDESupport - Failed to update passphrase for (user UUID)

This has only occurred a couple times, outside of testing, but one user reported their password had been changed over a week prior to them being 'Locked Out' after a restart. Of course, they hadn't restarted the Mac since changing their password.

If this is correct behaviour, then I must be missing something because even after changing their password, a User must still enter their old password after restarting their device.

If this is incorrect, I'd love to gain a better understanding as to how FV2 processes the updating of passwords and where I can see a verbose log of the failure.

Thanks for your time.

[bentoms]

@jyergatian, ah. Yep that doesn't sound right.

I'll light the FV signal now & see if @rtrouton has anything to add.

[rtrouton]

That error usually means something's not working right in either opendirectoryd or in the Mac's recovery partition. One way to narrow down the problem would be this:

1. Decrypt the Mac in question
2. Replace the Recovery HD partition on the Mac with a new one. One way to do this is with a Recovery installer package, generated by Per Olofsson's Create-Recovery-Partition-Installer tool:

https://github.com/MagerValp/Create-Recovery-Partition-Installer

1. Once a new Recovery HD partition has been installed, re-encrypt the Mac and see if the problem persists.

[jyergatian]

Hm. Thanks for the recommendations. I'll perform them on Monday and test. I'm not sure which I hope for more; the Recovery Partition which is created by DeployStudio during the initial imaging process or opendirectoryd, which is embedded into the individual images...

[davidacland]

I've seen the same behaviour at a few sites on 10.8. It affected lots of Macs and restarting with the ethernet cable plugged in numerous times (definitely connected to AD ok) the FV password didn't update.

I could "correct" the issue by prodding fdesetup, i.e. performing almost any action using fdesetup seemed to force it to back into sync, until the next password change.

I haven't seen it on >10.9 though.

[mapurcel]

We are seeing this consistently on 10.10 Yosemite. We use AD Mobile accounts and have a small group of test users in IT on 10.10 - so far we have seen every user get out of sync on a password change.

Some have changed passwords on a different machine, some on the affected machine, but we haven't figured out a way to get the passwords to sync up yet. On 10.9 we never really saw this problem.

[jyergatian]

This issue is still plaguing us, but it doesn't appear on every machine. We've been performing upgrades to 10.10.3, and now we've migrated our configuration to a 'thin-image', using the Factory OS and Recovery HD that came with the Mac. Regardless, the issue has appears on a wide range of devices, covering all variables.

The solution is to remove the user from FileVault, then re-add - supplying the new password. This is extra cumbersome as our configuration has only the user as the registered FileVault user. Long story short, we have to add the localadmin to Filevault, juggle the AD user, and remove localadmin.

I'm unsure what the root cause is, we've seen it happen on 10.9.5, 10.10.2, and 10.10.3. Version and deployment method appear to have no effect on the problem. We've adjusted our method for activating FileVault from an automatically-installed Configuration Profile to the JSS FDE Configuration and a policy within Self Service, run by the AD user. We've even gone so far as replacing the Recovery HD using the Create RecoveryHD Package tool mentioned by @rtrouton.

[davidacland]

I've had the same issues. Just adding another FV user and then removing them seemed to refresh the whole thing for me. I didn't have to touch the affected user's account.

Still all a bit too flakey for my liking though.

[jyergatian]

Thanks for the response @davidacland. The next one that comes by, I'll give that a test as well.

I don't mean to spam the discussion with log output, but maybe comparing opendirectoryd.log will find some form of similarity which would contribute to this issue. The following is a opendirectoryd.log from a previously effected computer. The issue was resolved several weeks ago by juggling the user in and out of FileVault. As you can see, an issue still exists. The only edit i've made to this log output is replacing our AD NodeName with 'Company'.

2015-05-11 08:36:37.921333 PDT - AID: 0x0000000000000000 - opendirectoryd (build 382.20.2) launched... 2015-05-11 08:36:37.925532 PDT - AID: 0x0000000000000000 - Logging level limit changed to 'error' 2015-05-11 08:36:37.951840 PDT - AID: 0x0000000000000000 - Initialize trigger support 2015-05-11 08:36:37.960231 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/SystemCache.bundle' 2015-05-11 08:36:37.969394 PDT - AID: 0x0000000000000000 - Registered node with name '/Active Directory' as hidden 2015-05-11 08:36:37.970321 PDT - AID: 0x0000000000000000 - Registered node with name '/Configure' as hidden 2015-05-11 08:36:37.970907 PDT - AID: 0x0000000000000000 - Discovered configuration for node name '/Contacts' at path '/Library/Preferences/OpenDirectory/Configurations//Contacts.plist' 2015-05-11 08:36:37.970915 PDT - AID: 0x0000000000000000 - Registered node with name '/Contacts' 2015-05-11 08:36:37.971412 PDT - AID: 0x0000000000000000 - Registered node with name '/LDAPv3' as hidden 2015-05-11 08:36:37.972739 PDT - AID: 0x0000000000000000 - Registered node with name '/Local' as hidden 2015-05-11 08:36:37.973836 PDT - AID: 0x0000000000000000 - Registered node with name '/NIS' as hidden 2015-05-11 08:36:37.974423 PDT - AID: 0x0000000000000000 - Discovered configuration for node name '/Search' at path '/Library/Preferences/OpenDirectory/Configurations//Search.plist' 2015-05-11 08:36:37.974431 PDT - AID: 0x0000000000000000 - Registered node with name '/Search' 2015-05-11 08:36:37.977557 PDT - AID: 0x0000000000000000 - Discovered configuration for node name '/Active Directory/COMPANY' at path '/Library/Preferences/OpenDirectory/Configurations/Active Directory/COMPANY.plist' 2015-05-11 08:36:37.977600 PDT - AID: 0x0000000000000000 - Registered subnode with name '/Active Directory/COMPANY' 2015-05-11 08:36:37.977650 PDT - AID: 0x0000000000000000 - Registered placeholder subnode with name '/Active Directory/COMPANY/All Domains' 2015-05-11 08:36:37.999768 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/legacy.bundle' 2015-05-11 08:36:38.005957 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/search.bundle' 2015-05-11 08:36:38.011258 PDT - AID: 0x0000000000000000 - '/Search' has registered, loading additional services 2015-05-11 08:36:38.011266 PDT - AID: 0x0000000000000000 - Initialize augmentation support 2015-05-11 08:36:38.014254 PDT - AID: 0x0000000000000000 - Successfully registered for Kernel identity service requests 2015-05-11 08:36:38.014261 PDT - AID: 0x0000000000000000 - Adjusting kernel ID cache (100 -> 250) and membership cache (100 -> 500) 2015-05-11 08:36:38.032122 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/PlistFile.bundle' 2015-05-11 08:36:38.037342 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/FDESupport.bundle' 2015-05-11 08:36:38.044266 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/AppleID.bundle' 2015-05-11 08:36:38.060372 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/ConfigurationProfiles.bundle' 2015-05-11 08:36:38.061359 PDT - AID: 0x0000000000000000 - Registered subnode with name '/Local/Default' 2015-05-11 08:36:38.068586 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/ActiveDirectory.bundle' 2015-05-11 08:36:38.074993 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/ldap.bundle' 2015-05-11 08:36:38.076951 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/Kerberosv5.bundle' 2015-05-11 08:36:38.081286 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/NetLogon.bundle' 2015-05-11 08:36:38.081698 PDT - AID: 0x0000000000000000 - Registered subnode with name '/Active Directory/COMPANY/site1.COMPANY.local' as hidden 2015-05-11 08:36:38.082381 PDT - AID: 0x0000000000000000 - Registered subnode with name '/Active Directory/COMPANY/All Domains' 2015-05-11 08:36:38.082643 PDT - AID: 0x0000000000000000 - Registered subnode with name '/Active Directory/COMPANY/Global Catalog' as hidden 2015-05-11 08:36:42.995136 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/configure.bundle' 2015-05-11 08:36:42.996426 PDT - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/keychain.bundle' 2015-05-11 08:46:36.000310 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 09:09:12.422356 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 10:24:00.671627 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 10:55:41.017817 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 11:15:01.648834 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 11:40:08.815115 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 12:56:19.175859 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 13:23:17.077299 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 13:30:09.603729 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 14:49:50.939314 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 15:44:00.977475 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 16:43:02.505962 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC 2015-05-11 16:47:00.556304 PDT - AID: 0x0000000000000000 - Module: FDESupport - Failed to update passphrase for 70A0C19B-36DB-4C00-906C-8C4CBDF50DAC

[jyergatian]

Here's our dsconfigad

Active Directory Forest = site1.company.local Active Directory Domain = site1.company.local Computer Account = abc-def-001-m$ Advanced Options - User Experience Create mobile account at login = Enabled Require confirmation = Disabled Force home to startup disk = Enabled Mount home as sharepoint = Enabled Use Windows UNC path for home = Disabled Network protocol to be used = smb Default user Shell = /bin/bash Advanced Options - Mappings Mapping UID to attribute = not set Mapping user GID to attribute = not set Mapping group GID to attribute = not set Generate Kerberos authority = Enabled Advanced Options - Administrative Preferred Domain controller = xyz.site1.company.local Allowed admin groups = Group Name Authentication from any domain = Enabled Packet signing = allow Packet encryption = allow Password change interval = 0 Restrict Dynamic DNS updates = not set Namespace mode = domain

[swapple]

We are seeing this issue also. Have 10.9 and 10.10 users with AD accounts, Mobile on the Macs, AD expires the password every 90 days. As we have more than 1 device (win box, mobile devices, etc), when the password changes elsewhere, the mac boots up and the old password gets into FV2, then the new password logs in. (expected). We are not finding how to resync the passwords as the rebooting still has the old password on FV2 and the new password on login.
We have tried the apple solution with the touch command and no luck.
sudo touch /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources

Any more thoughts on this?

[corbinmharris]

We use Centrify for AD management of the Macs. The support engineer stated our issues are caused by not using FV policies set in Centrify. I do have difficulty accepting this is the problem since we have been using Casper FV2 policy since Mavericks. The issues with AD/FV2 have just started this year.

I'm going to be at JNUC and hope that a JAMF support engineer with knowledge of Centrify will be available to discuss.

Corbin

[jpilege]

I'm running into something similar, but with a local account and not an AD account. I built up a Mid 2013 13" MacBook Air with a thin image that has our Admin account already created. The Mac is on 10.10.5.

After logging into the Admin account, I created the new hire's account from Users and Groups. Upon giving the Mac to the new hire, the password was changed within Users and Groups. The user is able to log in from a locked state or a log off, but when doing a restart the FileVault 2 password is still using the old password that I originally used when I first created the account. I have seen this before when the encryption isn't finished and once done, the password will sync with the log in password. With this Mac, it's not the case. I tried resetting the password again, but the original password stays in place.

FileVault is managed by Casper and will grey out the option to turn off FileVault in the System Preferences. Even unlocking the settings doesn't enable it. I don't remember if the option was greyed out as well on this user's Mac.

Will removing and re-adding the user fix this? Are there other suggestions to fixing the sync? This is the only Mac that has experienced this so far.

[kwatt29]

Has there been an update for handling this in 10.11? When running the sudo touch i get:

touch: /System/Library/PrivateFrameworks/EFILogin.framework/Resources/EFIResourceBuilder.bundle/Contents/Resources: Operation not permitted

[easyedc]

Throwing a tl;dr out there since it seems as if it gets a little off topic, but does having the user log out (not reboot) and log in sync things up? That's usually all it takes for when we occasionally come across this.

[mm2270]

The FV2 password sync issue has mostly gone away for us since around 10.10.3/10.10.4 or so. Whatever issue was in the older releases of Yosemite that caused FDESupport to fail to sync the passwords basically went away with that version and up, and has remained fixed as far as I can tell in El Capitan.
That being said, @kwatt29, are you seeing this problem under 10.11? Are the passwords for users being changed outside of the logged in account, like in AD or something? If so, then they will at least temporarily get out of sync, so that's not abnormal. However, it should fix itself once the user logs in to their account with their new password.

As for why you're getting that "Operation not permitted" error, that would be SIP blocking you, since /System/ is now a protected directory path.

[kwatt29]

@mm2270 I am seeing the problem on a couple of 10.11.2 machines as well as 10.10.5. We use local admins and stay as far away from AD as possible. I get the password policy through a configuration profile and FV2 through a policy.

I've tried using sudo pmset DestroyFVKeyOnStandyBy 0 as @jyergatian has pointed out that bug.

I feel like an idiot though because I've only been locking the machine and not logging the user out and logging back in -_- Will try logging out and logging back in as a solution tomorrow.

Interested if anyone has scripted adding and removing a user when a password change occurs.

[mm2270]

Interested if anyone has scripted adding and removing a user when a password change occurs.

Yes, I've done it and we are using it still for our clients that haven't updated to 10.10.4/5.

[KyleEricson]

I have the same exact issue it was not with JAMF but with AirWatch. We troubleshooted with Apple Enterprise Support and AirWatch Support they went back and forth on it. Seems like 10.10.3 and below works fine but anything higher has issues. Only have issues when using a MDM as when you turn on file vault without MDM it seems to work fine. Our Macs are AD bound just with the directory utility. AirWatch ended up sending a bug to Apple on this. This was back in September still no update

[kwatt29]

@mm2270 Do you mind sharing your script or give some insight on how you picked up a password change?

I would like to account for passwords changing outside of users and groups.

[mm2270]

Hi @kwatt29 I apologize for the confusion. I kind of misread your post. We aren't picking up a password change and doing anything automatically. That would be pretty difficult to do, if not impossible.
What I put together instead was a Self Service driven policy that runs a script. The script does several things.

1. Because we are all Active Directory accounts, it first checks to see if the logged in account is AD based.
   It also checks to make sure the Mac is joined properly to AD and can communicate with the primary domain controller.

2. It checks to see that a) FileVault is enabled and b) the logged in account is currently enabled for FileVault (uses fdesetup to check)

3. Once it passes these tests, it uses cocoaDialog to show a dialog explaining what will happen (general terms)
   It then asks them for their FileVault password. This is the one that they use to unlock the Mac, and is usually the now old password.

4. In the background, it uses this password to create a temporary "tempfv2" account on the Mac. This account has no user home folder, but has a valid record in local directory services.

5. It then uses the user's valid FV2 password to add this account to the authorized FileVault list. We do this because our Macs are mostly single use systems, so the primary user is the only one with an enabled FV2 account in almost all cases. We also don't enable the management account for FileVault.

6. Once that is verified to have worked, it will ask the user (again using cocoaDialog) for their current AD password. The one that they need to use at the regular username/password login screen, or to unlock the screen, etc.

7. It captures this, then removes the user's account from the FV2 list, then re-adds it back in, but using their current password as it adds it back in. it uses the previous "tempfv2" account to do this, since it is now the only FileVault enabled account on the Mac.

8. Once that is confirmed to have worked, it removes the tempfv2 account, and cleans up any leftover files and such and tells the user it was successful. It encourages them to reboot immediately to be sure they can log in past FV2 with their current password.

This whole process gets the password back in sync since its really removing them, then re-adding them to FileVault with their current password.
During all of this, there are functions in the script that will handle any errors, like if the user entered a wrong password for FileVault in the first step. It re-runs the function asking them for their password if that's the case, but I only give them 3 tries. If after 3 attempts its still failing, it stops and tells them to open a support case to get more direct assistance, since at that point we can assume something is wrong or the client isn't reading the instructions.

All of this requires that the client know their old password and their new one. If they don't know one or the other, they can't really use this process. This is mostly because there's no way to pull the Mac's Recovery key from the API or some other scripted method. Otherwise, I could use the Recovery key to add/remove accounts.

I hope the above helps explain how we are doing it. Its admittedly a hack, but we've had something like a hundred clients go through this process when their passwords got out of sync, with very few failures. The failures I've seen are usually either user error, or, in some cases, the password sync finally happened and the client wasn't aware of it because they hadn't rebooted in a while.

I don't know if I can post the script here as is. I would need to sanitize it a bit, because there are some specific items to our environment, like the domain controller check and so on.

[kwatt29]

Thanks for the thorough explanation @mm2270. I'm interested in how you could use the filevault recovery key to add and remove users to FV2. I'm not seeing anything on the man page for fdesetup. I'll open up another discuss and stop spamming this one.

@easyedc thanks for pointing out logging out and logging back in. This resolved the issue on a 10.11.2 machine today.

[mike_goddard]

(mm2270) did you ever get a chance to clean up that script, suitable for sharing on here? we're having the exact same issue and it sounds like your script is exactly what we need.

Thanks)

[simon_waters]

@kericson Did you get anywhere with the Air-Watch issue?

Seeing the same issue, when a Mac is enrolled in air-watch, something breaks the sync between filevault and login password.

It seems to be either temporary, or permanent. My main laptop is now permanently out of sync.

We've seen it on 3 of about 7 installs, so loathed to deploy Air-Watch for Mac OS X if this is going to happen a lot.

We have local admin account users currently, no AD, no complexity, just filevault, airwatch, and current Mac OS X. Also did Air-Watch reproduce this for you?

We have a second passcode related issue with Air-Watch on Mac OS X, where a passcode profile overrides the screensaver grace period specified in Security and Privacy profile. This is a real nasty, because it default back to 5 minutes. So you think your user's screensaver has immediately locked their laptop, but because you tweaked the passcode policy since you deployed the Security and Privacy profile you now have 5 minutes to walk up to and own their laptop.

Any pointers to details technical documentation on these issues very welcome.

[mm2270]

@mike.goddard Hi, no, I never did get around to doing that, but I can look at that at some point within the next week or so.
There are certainly other scripts similar to mine that do something along the same lines in case you need something in a hurry. I don't have any links handy, but I recall that @stevewood has a similar script around if I'm not mistaken?
Barring that, you can wait for me to post it here if its not a very time sensitive issue.

[stevewood]

Sorry @mike.goddard but the script I have is for moving domains. We moved from a local AD domain to a corporate wide AD domain and I have a script that did the move. It basically removed the machine from OD (we had a few bound to our OD) or from AD if it were bound to an old AD, then it bound to the new one. The final step was to add the user back to FV2 since their UID would have changed. You can find the script here:

Move AD Domain

To fix an out of sync FV password, you would need to remove the user from FV and then re-add them. You would need to have an admin user already in FV to do this, or have access to the FV key for that machine, because once you remove them you have no way of adding them unless you have the key or another user to use.

[mm2270]

Ah, yes, now I remember. Similar principal, but different use case entirely. Thanks for chiming in @stevewood!

[cainehorr]

We see this behavior ALL THE TIME. None of our Macs are bound to AD. Local accounts only.
We see this behavior on all macOS Versions from 10.10.x up to 10.14.x.
We also set the following CIS password controls.

• Number of max failed logins before account lockout - CIS Benchmark 5.2.1 (Scored)
• 5 min lockout (in seconds)
• Required password length - CIS Benchmark 5.2.2 (Scored)
• Number of required lower case letters in password - CIS Benchmark 5.2.3 (Not Scored) & 5.2.6 (Not Scored)
• Number of required upper case letters in password - CIS Benchmark 5.2.3 (Not Scored) & 5.2.6 (Not Scored)
• Number of numeric characters in password - CIS Benchmark 5.2.4 (Not Scored)
• Number of non-alphanumeric characters in password - CIS Benchmark 5.2.5 (Not Scored)
• Number of days until password expiration - CIS Benchmark 5.2.7 (Scored)
• Remember last used passwords - CIS Benchmark 5.2.8 (Scored)

Other odd behavior we see... User gets locked out after changing password, they need to wait 5 minutes - this IS expected... BUT... it also locks out the ability to use the FileVault Recovery Key during that 5 minute period.

Any thoughts? Anyone? Bueller? Bueller?

[gabester]

@cainehorr with respect to the password being out of sync there are some good tips here: Jamfnation: AD PW changes not syncing to FV on HS

[joshuaaclark]

TLDR: What to do when user password is out of sync with their FV2 password -- when they know their old and current passwords.

sudo fdesetup list | grep $USER   #where $user is the name of the user out of sync

It will return

USER,27E97FDA-252E-1D28-97E2-E11278DB2D21

then copy the long UUID and enter:

diskutil apfs changePassphrase disk1s1 -user 27E97FDA-252E-1D28-97E2-E11278DB2D21

You will be prompted for the old password and the current password.

[JMenacker]

@joshuaaclark this worked great for me in Big Sur - only issue is somehow the FV2 password screen will still not pass through the regular login screen even though the passwords are identical now. Any idea how I can get them to sync up again? User is currently authenticating with the same credentials twice now every time they reboot. Has anyone scripted this process yet?

[bainter]

@JMenacker Is com.apple.loginwindow set to DisableFDEAtoLogin?

[kishoth_p]

@JMenacker - Please follow this article (https://www.jamf.com/jamf-nation/discussions/38652/a-reliable-fix-for-filevault-2-password-sync-issue) and let me know if you are able to fix the password sync issue.