SSO parallels VDI

we have parallels RAS that allow us to login to VDIs. I have setup SSO on parallels it allows me to log in with my user name and password then once i select the vdi it tells me i have to be part of RDP group. I got in touch with Parallels and they suggested that iuninstall sophos endpoint and it worked. they sent me what to exclude, i did apply the exclusion and made sure that the newly  created vdis get the policy yet it is still not working. The other weird behavior is that when i uninstall endpoint reinstall it again single sign on remains working. I tried to turn off all the settings on the endpoint to determine what is blocking the sso it still doesn't allow me to log in. I have always to uninstall sophos to make it work. How can i determine what is blocking the sso? any tools or cmd to check what is happening in the background? why when uninstalling the endpoint and reinstalling it, it works? 

Parents
  • 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.

  • 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.

Reply
  • 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.

Children