Skip to main content

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.

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


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.


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


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/


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.


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


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


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



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


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.


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


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.


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.


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.


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.


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

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

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?


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


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.


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


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.


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.


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


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.


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


Reply