FDESupport?

[alex_merenyi]

Good Afternoon folks;

Ran into an interesting problem here that I wanted to see if anyone had seen before...

We're running AD mobile accounts on our MBP fleet, and all machines are encrypted under FileVault2 on 10.8.x. Each user is added to FV2 after their account has been imported from AD, and their AD password, when changed, syncs to FileVault, single-signs-on, and everyone's happy.

Got a user who is running into problems now, however - after a recent password change, their box is no longer synchronizing the password. Login keychain is good, old password seems to be gone everywhere except for their FileVault2 login. I've tried an fdesetup -sync, to no avail.

Did however find this, after we changed his password via System Preferences...

04/10/13 12:47:31.999 PM opendirectoryd[22]: Bug: 12D78: FDESupport + 6318 [disk UUID removed]: 0x0

Thoughts? I've never seen FDESupport anywhere.

[rtrouton]

FDESupport is one of opendirectoryd's modules:

http://real-world-systems.com/docs/opendirectoryd.1.html

I haven't run into it before now, but my assumption is that this module is how opendirectoryd helps keep the account password and FileVault 2 in sync.

Have you tried having the user log out to the regular login window, logging in, then restarting their Mac? Hopefully, logging in at the login window will trigger the password update process to occur, allowing FileVault 2 to use the new password at the pre-boot login screen.

fdesetup sync will not help you update the password; this is an area where the fdesetup sync command can be a little misleading. It does not pull users or passwords from your directory service. Instead, it's used to automatically remove users from a Mac’s list of FileVault 2-enabled users.

The general idea is that, as people leave and their accounts are removed from your AD or OD server, you can run sudo fdesetup sync on your Macs and those removed accounts will also be removed from the Mac’s FileVault 2 pre-boot login screen.

[alex_merenyi]

Rich - thanks for the clarification on Sync. Makes sense, as it decided not to give me any information, including with the -verbose flag, but it was worth a shot. :) Wouldn't be surprised to hear that opendirectoryd is behind the problems here - when he updated his password, it briefly un-flagged him as an administrator, so there may be a larger issue at hand.

Sadly, no go following the login window log in attempt. Interestingly, FileVault is definitely still attempting to pass the credentials. Following a FV2 login with his old password, it brings us to the OS X login window with a brief "shake" of the password field. It's passing the credentials, just the wrong ones.

[rtrouton]

OK, I'd recommend looking at the OS then. <hamlet>Something's rotten in the state of opendirectoryd.</hamlet>

[SamF]

I've seen this type of behavior under a different set of circumstances. Updating an account password and then attempting to add the user to the list of FV2 enabled users without first logging out will also cause the passwords to become out of sync and stall between the pre-boot and login windows.

I suspect this has to do with the login keychain not getting updated until the next login. Resetting the password again through System Preferences resolved the issue in the scenario I describe. Hopefully, that will help out in your case as well.

[hkim]

We're seeing this in our environment on rare occasions, it seems a very small number of our 10.8 machines are running into this issue over WiFi, because we never seen this over Ethernet yet (but with a growing fleet of Airport by default machines, it's a bit disconcerting), and we can't nail it down to an exact process of password change where FV2 gets out of sync thus it's been hard for us to diagnose.

The AD password gets change successfully, everything is fine logging into the machine, login keychain, authentication, kerberos tickets, but FV2 is still holding onto the old password for no explainable reason, and in our testing, not every time. This started with a 10.8.2 machine and upgrading to 10.8.3 seemed to bring the passwords back into sync without needing a password change. But we've seen this also on 10.8.3 machines, so doing an update isn't a fix.

[thoughton]

Just discovered this problem today. What seems to cause the problem for us is removing the .efires files to modify the FV2 boot screen to show our login banner. I'm getting the same errors on a 10.8.3 MBA and 10.8.4 MBA. Anyone have any thoughts on where to go from here? No combination of logging in/logging out/reboot/shutdown-poweron has worked. The only that has worked is removing the .efires files again once the passwords are out of syn. When changing the PW in System Prefs I get a message in the Console that says "System Preferences: Can't ODFDEResetPassword because of NULL authorizationRef!"

I also see a similar "opendirectoryd: Bug: 12E55: FDESupport + 6318 [user-UUID-here]: 0x0"

I'm stumped since we want to add the login banner but obviously want users passwords to sync. Thoughts?

[rtrouton]

Mike Boylan mentioned in another thread that there's an Apple-recommended command to update the FileVault 2 login window without deleting the .efires files:

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

The thread is here:

https://jamfnation.jamfsoftware.com/discussion.html?id=7531

Hopefully, this command allows you to update your FileVault 2 pre-boot login screen without losing password sync.

[thoughton]

rtrouton and mboylan have solved my issue. For those of you that need it in the future the answer is here:

https://jamfnation.jamfsoftware.com/discussion.html?id=7531

See mboylan's post. Thanks guys!

[jyergatian]

Hi everyone,

All our 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

It appears to be related to pmset DestroyFVKeyOnStandby - also available via Configuration Profile, in the Security>FileVault tab. With this enabled, FDESupport can't update the passphrase.

A more detailed post can be found here by @n8felton http://www.openradar.me/16410396