I wanted to reach out and see if anyone else is experiencing this issue.
Passwords changed by any method are not being updated in FileVault 2 with an Active Directory account when a system is encrypted using McAfee Native Encryption. The password used when initially setting up FileVault 2 on a system with MNE is still used to login to the FileVault 2 pre boot screen. A computer using the same Active Directory account with a system encrypted with the standard FileVault 2 configuration, password changes are reflected in FileVault 2.
Steps to Reproduce:
1. Bind the Mac computer to an Active Directory Domain.
2. Encrypt the Mac using the FileVault policy for MNE in EPO.
3. Enable the Active Directory users in FileVault 2 in the Security & Privacy Preference Pane of System Preferences and enter their password to be synced with FileVault 2.
4. Reboot the computer and login to the FileVault 2 pre boot environment with the Active Directory Account.
5. Change the password either through the Password Change in AD Users and Computer, or the User & Groups Preferences Pane of System Preferences.
6. Reboot the computer and attempt to login to the FileVault 2 pre-boot environment with the new password.
7. New password will not be accepted, but using the old password will allow the user to login to the FileVault 2 pre-boot environment.
8. Repeat password change will have the same result.
Passwords change by any method should be reflected in the FileVault 2. A system encrypted using the standard FileVault 2 configuration are able to reflect a password change.
Has anyone else noticed this behavior?
Are you using MNE password policy ?
If yes, Disable the MNE password policies and leave these setting to Active directory. I guess AD password is not syncing with the client machine.
Have you gone through the log file ? What it's saying ?
Hi Sathish L,
Nope, we are not using a MNE password policy. We are allowing AD to manage the passwords on the Mac. Unfortunately per the request of McAfee support I reinstalled a fresh copy of Mac OS X and enabled FileVault through the standard means on the computer I was using for testing. So I don't have the log files intact anymore. Any other suggestions?
Hi Sathish L,
So I did some more testing. I just finished installing a fresh version of Mac OS X 10.9, bound it to our AD domain, and encrypted the hard drive with MNE. I logged into the computer with the AD test account that I have been using with MNE initially to make sure that they can log into the FileVault 2 preboot envirnoment successfully and they can. I then changed the password from our AD controller, logged out of the computer and logged back in to make sure that the account can log in past the login window with the new password and it could. I then rebooted the computer and attempted to log into the FileVault preboot environment with the new password. This was unsuccessful. I was not able to log in with the new password, but I was able to login with the old password. When I look in the cousole, I don't see anything out of the ordinary in the /Library/Logs/Native Encryption.log. But when I look at the /var/log/opendirectoryd.log I see:
2014-01-27 10:13:29.327177 EST - Module: FDESupport - Failed to update passphrase for (GUID)
Note, I've removed the guid from the line, but you probably know at what I'm getting at. I also have to mention, that I have a second computer setup with the same AD account. The only difference is that this computer was encrypted using the FileVault tab in the Security and Privacy pane of System Preferences. When I change the password for the AD account, the FileVault 2 password is updated properly with FileVault 2 and I can login past the FileVault 2 preboot environment with the new password.
So this leads me to believe that it is MNE causing the password to not sync between the Directory Service and FileVault 2. This computer also has nothing installed on it other than the OS and standard default apps that come with Mac OS X. There are no other applications installed on this computer that could interfere with the password synchronization.
I figured out this issue, Once you change the password from the AD. You can enter the new password on EFI screen (Pre-boot). At the moment you entered the new password, you will get one pop-up window. there click on "update key chain" and enter the old password (it won't take the new password). And enter the new password on MAC logon screen. Now, reboot the machine and logon with administrator account (local\domain). Once you logon with administrator account. The new password which you changed for particular user. That password synchronisation will happen from client to AD. I guess this is the expected behaviour, in order to sync the new password with AD. You should logon with admin account. Reboot and check the status, i guess this will work.
Hi Sathish L,
Thanks for the response, unfortunately that has not worked in my testing. Since the Pre-boot environment is initiated through the recovery partition, there is no access to the OS and user account information to change the login password or keychain password from the pre-boot environment. That is all handled by the Directory Service. In my testing it didn't matter what option I chose for resetting the keychain password. All options, entering the old password, creating a new login keychain, and continue logging in without changing the keychain password, all had the same affect and the passwords were synchronized to the FileVault 2 preboot environment. Additionally all the user accounts that I have been testing with have been administrators on the machine so there shouldn't be an issue with administrative access to the file system. Lastly in our environment we use Oracle Identity Management to sychronize our passwords between all of our systems. So the password is changed outside of the client. By default we do not allow users to change their password from the OS, as this causes the password to be changed in Active Directory only, and not on all of our systems leaving passwords out of sync. However, I initially thought that was causing the issue, so I enabled the password change on one of my test accounts. However, when I used the FileVault 2 key and got to the login window and attempted to change the password on this account, it would not let me change it. The log in window "shook its head." That being said, if I got into the Users & Groups pane in system preferences and change the password for the account there, which was changed successfully, log out of the computer and back in, change the keychain password accordingly, the password change was still not synchronized to the FileVault 2 pre-boot environment. On the same system using a local account the password changes are synchronized to the FileVault 2 pre-boot environment successfully. Like I said in my first post, this is not an issue for clients using the FileVault Pane in system preferences to enable FileVault 2 or Local accounts, but with Active Directory Mobile Accounts using MNE. I have gone through the same process on a machine that was encrypted useing the FileVault 2 pane in system preferences, and using the fdesetup commands in the Terminal, and have had no issues with password changes using the same Active Directory accounts. All password changes using and Active Directory Mobile Account have successfully synchronized with the FileVault 2 pre-boot environment.
On a side note, I have opened a support ticket with the MNE team, but haven't gotten a response to the issue yet.
Has there been a solution for this?
Per KB81289 there is a workaround but it does leave holes open.
I have tested this with every password change scernio and the change syncs with preboot instantly.
As adhuston stated there are no issues when manually managing FileVault, thus leaves me to believe that despite McAfee pointing the finger at Apple it is with MNE.
Just going to add a bump to this to see if there is an update at all. We're hoping to complete a rollout of MNE this summer, and this is currently a huge draw back to that plan.
Bumping again, hopefully there is some updates on this. My deadline is upon me and I am forced to start deploying.