Is anyone else's ENS self protection blocking the Internet Explorer file ie4uinit.exe? The file is located in the correct path of C:\WIndow\System3\ie4uinit.exe which means it should be the legit file so it should be okay to exclude from self protection. I am just not sure why this file would be getting blocked if it is a legit windows file.
From the self protection event you should be able to see that ie4uinit.exe must be accessing McAfee ENS file\registry\process. Do you see a event like "IE4UINIT.EXE, which tried to access HKCU\SOFTWARE\MICROSOFT\INTERNET EXPLORER\MAIN\ENABLE BROWSER EXTENSIONS, violating the rule "Web Control - Protect plugin registry keys and values" ? This event can generated when trying to enable/disable "Enable third-party browser extensions" among other actions. So this is expected behavior protecting McAfee ENS file\registry\process which prevents disabling protection on the client.
So you are saying the end user that is on the computer is trying to enable a third-party-browser-extension and that is what is causing the file to try and change the registry keys? Also, is waiving the file path C:\WINDOWS\System32\ie4uinit.exe a viable option?
"Enable third-party browser extensions" is one of the ways that can generate the event. The event is expected if a non-McAfee process tried to access\change McAfee ENS registry entries.
This is happening to us as well. Why would Endpoint Security want to prevent Internet Explorer from enabling the Endpoint Security Web Control plug-in? And what do we need to do to stop it from showing up as blocked.
Thank you for replying here. Kindly please find below the explanation for this behavior from our Engineering:
This is as designed. If the keys were unprotected, then any user could disable browser extensions, and break Web Control in IE.
Related KB86948 explains to disable self protection to alter the value.
When the "Enable Browser Extensions" key is not present, IEs default behavior is yes, or enabled for Workstation OSes. For Server OSes, the default value is no, or disabled.
To prevent blocking the action:
1. Temporarily add a Self Protection exclusion.
2. Temporarily disable the registry protection option of Self Protection, or set it to Report only.
3. Temporarily disable Self Protection.
As explained above this is not meant to block the enabling of extension, but to block the disabling of the extension. Unfortunately, the process in use for both these action is the same and hence this behavior is expected. I sincerely hope this answer helps.
Now that I have come across this post owing to a recent response, I could not stop myself but notice this post and hence I am responding to this as well.
No, This is not really a good option as it would beat the very purpose of the self-protection in place. You can add this as a temporary exclusion though and it should still help. You can follow any of the 3 suggestions available in my previous post, however adding a permanent exclusion for the process ie4uinit.exe to Self protection is not recommended by us.
I sincerely hope this helps as well!