In testing Scenario 2 some more it appears the results are inconsistent. I have done the scenario 5 different times and 3 out of the 5 worked as expected where McAfee took the password set in step 7 as soon as the user rebooted. However, 2 times it did not take that password. Is there a timing issue we need to be aware of?
From experience and the only way I have observed it update/change the PBFS password is if the user authenticated in the PBFS is the same user that is authenticated into windows and they process the ctrl+alt+del.
Take a look here:
To be able to change a user DE/EEPC preboot password, all of the following criteria must be met:
- DE/EEPC must be installed and activated.
- The DE/EEPC Product policy must have Single Sign On (SSO) enabled and the option Synchronize Endpoint Encryption password with Windows selected. It is also advised to enable Must match user name. To support this, see KB75216.
- Client system is not set to Autoboot. For details, see KB65824.
- The User that is logged into preboot must be the same as the Windows user. For details, see KB75216.
- The password change must be performed after pressing CTRL+ALT+DEL (Credential Provider) screen.
- The system did not boot utilizing Out-of-Band to bypass preboot.
- An Emergency Boot was not performed on the client to bypass preboot.
- An Administrative recovery was not performed on the client to bypass preboot
Thank you for this! According to KB79339, in order to change a user's EEPC password the same user has to be logged in at preboot and windows. I did not realize that was a requirement. We are on version 7.0.x so we do not have the option to require endpoint encryption logon like KB75216 suggests.
So Senario 2 should look like this instead:
1. User cannot login to the McAfee preboot environment. He cannot remember his password.
2. An EEPC admin that has access to all machines logs in at preboot and logs into Windows (since this is his first time logging into this particular machine)
3. EEPC admin remotes to a machine and access active directory.
4. EEPC admin changes the users password in Active Directory.
5. EEPC admin logs out of the remote machine and logs out of Windows on the user's laptop.
6. Laptop is rebooted and a self-recovery or admin recovery is done on the users account to set the EEPC password to the password set in Step 4.
7. User is required to login at Windows the first time to update the SSO credentials
I think you may be over complicating the process. When I have users that cannot authenticate in the PBFS here are the steps I follow.
Perform a user based admin recovery via challenge response codes, however instead of the default options in ePO to perform a machine recover, choose User Recovery > Reset Token, then select the user for that system and provide that response code. What this does it allows the user to recreate their password and recreate their recovery questions/answers. Once that is completed, they will be challenged for a Windows login. Why didn't it do the SSO? I believe this is a security step taken to ensure you say who you are. Upon a successful windows authentication the machine boot and all is well. After the next boot SSO will engage.
Works every time, and its a good user experience.
That is exactly what I have instruted the analysts to do. I think they were trying to shortcut having to do a challenge and response, but they must in this case. Thanks again!