We have noticed an issue with DE running on Windows 10 Creators edition where if the user changes their password via Control-alt-delete, the DE Host Agent doesn't capture the change and update it in the PBA login. After rebooting, the old credentials must be used to unlock the system.
Once the system is unlocked, DE attempts to SSO into Windows with the old credentials and then fails. Upon successful login after SSO failure, the credentials are properly captured and updated in the PBA (as expected).
What is odd here is that the initial password change is NOT captured. It works as expected in Windows 7. I opened a case with McAfee support, and we came to the conclusion that something funky is going on with the credential providers and preventing password changes from being captured.
This article here is what prompted the thought: McAfee Corporate KB - Single Sign On fails on systems that have third-party credential providers ins...
McAfee support told me to delete or disable the FIDO Credential Provider (which is a default provider with Windows 10 Creators edition as far as I can tell). MS and the FIDO Alliance worked together to provide this for Microsoft Passport login. Upon disabling the FIDO credential provider via local group policy and rebooting, McAfee DE does properly capture the password changes.
Another colleague is also running Windows 10 Anniversary edition *without* the FIDO credential provider, and claims the same problem exists for himself. It's entirely possible there are other credential providers intercepting DE from capturing the password change.
I am curious if anyone else has run into this problem?
Came across this old post from SafeBoot - Particularly the part about 2 different providers capturing the login credentials: https://community.mcafee.com/thread/49040?start=0&tstart=0
If you're changing it during a ctrl-alt-del event, then EEPC has a network provider which Windows notifies of the change. It then immediately tries to change the pre-boot password. Then, at some point in the future, an EPO policy update will occur, and that new password will get sent up to EPO for distribution to other machines.
When you do a SSO login, if that fails and you type new Windows credentials, the EEPC credential provider will pick up the change and do the same thing.
Two different systems, network provider for an initiated change, and credential provider for a change during a login.
In our troubles here, the Network Provider is not properly capturing the user's credential change. The Credential Provider duing SSO failure *IS* capturing it.
And yes, on the system in question: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\HwOrder have:
ProviderOrder = RDPNP,LanmanWorkstation,webclient,PGPpwflt,MfeEpePcNP
We have been seeing similar issues with the same version of DE and Windows 10, but also getting a hang and or extended login to Windows some can last all day with newly imaged machines and or machines that have been in use suddenly getting this hang aswell as prompts saying the preboot password needs to be updated.
Sorry if it looks like im hi jacking thread
No worries about the hijacking - After going through several tiers of technicians, I finally got the following update from a McAfee SEO:
The good news is, your case appears to be similar to others that we have escalated to us that our development team is already working on. As such, we have been actively working on your issue even if we have done a poor job of keeping you updated. There are a few things that I was hoping you could verify for me.
Please let me know. My development department is currently waiting on Microsoft’s development team to provide them a fix. I do not have a timeline, but the other reported cases with this issue have all been the same thus far.
I should note that a lot of our systems have an Ivanti/LANDesk Virtual Smart Card Reader installed. But, I have not confirmed if the problem is present or not on a system without any type of physical or virtual smart card reader.
i want to ship in on that topic. We have the same problem that you described in our company on all Windows 10 devices
Regarding the questions from McAfee in our case:
1. Only on Windows 10 does this issue occure
2. We have no 3rd Party Credential Providers, LSA Notification Packages, Network Providers other than the McAfee ones
I have noticed that on Windows 7 the Logfile:
which is located in:
is existing and is recording all actions on the client. For expample Password changes:
2017-11-15 18:06:41,031 00001030 EPEPC_cp_provider:etUsageScenario (9): ++++ EPEPC_cp_provider 0x0329F710
2017-11-15 18:06:41,032 00001030 EPEPC_cp_provider:etUsageScenario (9): SetUsageScenario: scenario = CPUS_CHANGE_PASSWORD
On Windows 10 this log file is complety missing! This leads to believe me that the LSA Notification Package/Network Provider DLL from McAfee which is
is for some reason not working at all on Windows 10.
Iam a little bit suprised that such a big bug exists and is not fixed at the moment.
I'll be completely honest and say I had no idea that log file even existed. Thank you for alerting me to its presence!
What version of Windows 10 are you on? It actually *IS* present on my Windows 10 Creators Edition system. Build 15063
we are currently in the phase of migrating from
Windows 10 1511 (10586)
Windows 10 1607 (14393)
AFAIK we have the issue on both Windows 10 Builds.
Are there any errors in your Logfile?
Continuing on this i found out that on Windows 10
this registry key is 0:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee EndPoint Encryption\MfeEpePc\Policy]
Which prevents EEPC to log to the EpePcCpLog.log Logfile.
Why that behavior is different than on our Windows 7 devices where this key is 1 I don’t know. I have activated the the log now on our Windows 10 devices for further investigation