SSO parallels VDI

Hard to say from that but your comment:

The other weird behavior is that when i uninstall endpoint reinstall it again single sign on remains working

...is perhaps the most significant. 

I assume when you re-install and it continues working, is this until the first reboot after re-installing?

I just wonder if this is due to the injection of a Sophos module into one or more processes.  This only happens on process creation so if the "processes of interest" are already running, then until the reboot they wouldn't get the module.

As a test, if you disable Tamper on the computer and rename:

C:\Program Files\Sophos\AutoUpdate\SophosLaunchUpdate.exe to C:\Program Files\Sophos\AutoUpdate\SophosLaunchUpdate.off 
This will just prevent updates and the software repairing itself temporarily so rename back one done.

Then rename:
C:\windows\system32\hmpalert.dll to C:\windows\system32\hmpalert.dll.off
C:\windows\syswow64\hmpalert.dll to C:\windows\syswow64\hmpalert.dll.off

That will prevent hmpalert.sys injecting those modules into processes as they start.  

Does that help narrow it down to the hmpalert.dll module being loaded?

I was mistaken, you are right after reboot it stops working.

I tried above steps it did not help as well.

I was mistaken, you are right after reboot it stops working.

I tried above steps it did not help as well.

OK, so that has ruled out HMPA mitigations.  With the hmpalert.sys driver still loaded CryptoGuard, the anti-ransomware feature is still enabled but I'm not sure it sounds like a file system level issue.

You can rename:
C:\windows\system32\hmpalert.dll.off
and 
C:\windows\syswow64\hmpalert.dll.off
back, but maybe leave SophosLaunchUpdate.off  or now to prevent an update changing and recovering something whilst troubleshooting. 

There is also the SophosED.DLL module that is injected into processes that start, this is primarily used for DLP but is starting to be used more widely. It is the SophosED.sys driver that injects those. You could perform the same test renaming:

C:\Windows\System32\SophosED\SophosED.dll
C:\Windows\SysWOW64\SophosED\SophosED.dll

In the same way and run Process Explorer and search for the DLL SophosED.dll to see where it is loaded.

Otherwise, I'm not familiar with the application or the nature of it but if you stop the "Sophos Network Threat Protection" service and the driver:

sc.exe stop sntpservice
sc.exe stop sntp

Does it work then?  That will remove the WFP filters from the BFE config.

At the moment it seems like we just need to identify the component causing the issue.

I was able to identify the component, I turned off Exploit mitigation and worked. What would be the best practice here without exposing our systems? especially it will be adjusted to servers too. 

So no loading the hmpalert.dll into one or more process helped?

Do you know which process or processes are significant?

Under exclusions in the Threat Protection policy or even globally, there is the exclusion type:

"Exploit Mitigation And Activity Monitoring (Windows)". 

----


----


At the bottom of that dialog there is a "Exclude Application By Path" section where you can add a path to an exe, e.g.:

----

----

In this case. When defined and the policy arrives at the computer, PolicyInjectionExclusions under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hmpalert\Config


will contain this configuration.  The next time process starts, the hmpalert.sys driver will not inject the hmaplert.dll into it.

You can check that in the log file: "C:\ProgramData\HitmanPro.Alert\Logs\sophoshmpaservice.log" the process excluded is no longer listed as that log details the mitigations applied to the process.

Nope only the exclusion part helped alot! Thank you!