FileVault2 very slow to sync new AD Password change

Contributor III

Hi all,

I have a few FileVault test users and there have been instances of the FileVault password not updating after a password change, they restart the Mac and it will only accept the old AD password, after a few hours they try a restart again and the password has then finally updated.

We use McAfee MNE to manage FileVault
Active Directory Mobile Accounts
Password change via ADPassMon (System Prefs > Users & Groups)
All the password changes are taking place on our network whilst the Mac can reach our AD

Does anyone know which mechanism updates the FileVault password so it matches the AD login password ? i'm wondering if there's any way to force it or at least monitor it's success.

I've had a look at fdesetup but there doesn't seem to be any relevant commands with that, also @rtrouton has a great article that says there could be an issue with the UUID, i've checked on the Mac and in AD and the UUID for the user is the same.

any input greatly received!


Contributor III

HI May, we've had this issue in our environment using MNE to manage FV2 encryption with AD bound accounts. Do you use Casper at all in your environment?

The issue I've seen also is that MNE does not always communicate back and forth with the mac when it escrows or generates a new in the event of recovery access the key that is logged in MNE is not the same that is needed to unlock the some point it changed but did not escrow or complete the hand off.

So while not directly related, I'm curious if some of these are related in that sense?

Contributor III

Check to see if DestroyFVKeyOnStandyBy is enabled. If not try the change password process with the power management settings disabled via pmset.

Honored Contributor

I have been seeing FileVault passwords taking up to many days to sync up after Active Directory password changes (done through System Preferences > Users & Groups). We aren't using anything like McAfee to manage it. It's random - some passwords sync almost immediately while others really do take days and in one case a few weeks. I would maybe guess your issue isn't so much with McAfee as it is with whatever mechanism built into the OS is supposed to make it sync.

Contributor III

@wait We haven't had any issue with the ePO communication, as @AVmcclint (thanks) says i don't think it's related to the McAfee MNE part, it seems to be whatever in the OS syncs the FV password, if i can understand what manages that sync i may be able to force or monitor it.

Re your ePO communication issue there are a couple of commands you can run to force and check communication to the ePO
/Library/McAfee/agent/bin/cmdagent -h will show you all the options -i will tell you the last check in time.
we also have an EA that checks /Library/Logs/Native Encryption.log for "Recovery key escrowed to ePO server successfully"
so we know it's placed the key on the server correctly.

@htse Could the DestroyFVKeyOnStandyBy setting be related to the password not updating the FV password ? i had a read through this and couldn't see any connection,

I just found this which says it does affect the password sync, though this was on 10.9.2 so
not sure if still relevant, plus i'd like to keep DestroyFVKeyOnStandyBy off so the users don't need to login twice after sleep.


Contributor III


that Open Radar reference was the same article I came across to troubleshoot that same problem in macOS 10.11 and 10.12. It also supported by the McAfee article referenced at the bottom.

Contributor III

Thanks @htse

I just checked on our ePO and the Destroy FileVault key when going to standby option is not enabled for MNE
and looking at the Mac using "pmset -g" i get "DestroyFVKeyOnStandby 0" (off),
so the issue w're seeing can't be related to that, i wish it was !