Outlook Add-in + SRP

[offbyone 10]

Hi.

We have the problem that the ESET Outlook Add-in does not work together with Microsoft Software Restriction Policies. The ugly thing is that normally when something is blocked by SRP you will find a detailed message in the event logs. However with Office add-ins this is not the case, so it is nearly impossible to track this down.

When all places where users are not allowed to write are white-listed the ESET Outlook add-in still fails to load. I have to white-list C:\ to get the add-in to work which is similar to disabling SRP at all.

Any suggestions why this fails and how to track down. it is the only Office add-in not working with SRP here so far.

Thanks for your help.

[Marcos 5,074]

I'm not sure if this is something that could be solved; probably you should contact MS support since it's they who created MS SRP. We too have HIPS for hardening the system against ransomware attacks, however, we also tell that the extra HIPS rules may cause issues in certain legitimate cases and the user may need to disable or adjust some of the rules to avoid issues.

[itman 1,659]

Has Eset Outlook Add-in been allowed in Group Policy per this article: https://docs.microsoft.com/en-us/office365/troubleshoot/group-policy/office-add-in-not-loaded ?

[offbyone 10]

Here is a workaround for the problem:

Add a path rule for "C:\Program Files". Although this sounds stupid as there is already a default rule in place which covers this directory, there is a difference.

The default rule specifies a registry key where the path is stored to be whitelisted, whereas the rule you have to add directly specifies the path.

There seems to be an incompatibility with MS SRP if a software loads a DLL in a certain way which leads to a path rule not correctly evaluated if it is specified via registry key. Took a long time to find it out, so others having the same problem can adopt this workaround.

Although 99,9% of software is not affected by this problem, ESET add-in however is, so be prepared.

Cheers.