Thread Info
  • State Verified Answer
  • Replies 7 replies
  • Subscribers 14 subscribers
  • Views 856 views
  • Users 0 members are here
Options
Suggested

SSO parallels VDI

Reem Jalal Eddine

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

    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?

Reply
  • 0

    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?

Children
  • 0 in reply to Sophos User930

    Well never thought of rebooting, sometimes you miss importatn steps.

    I did try to turn off the tamper protection to one of the VDIs and it worked but for other VDIs it did not this is driving me crazy.

    Ill try you solution.

  • 0 in reply to Sophos User930

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

    I tried above steps it did not help as well.

  • 0 in reply to Reem Jalal Eddine

    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.

  • 0 in reply to Sophos User930

    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. 

  • +1 in reply to Reem Jalal Eddine

    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.

  • 0 in reply to Sophos User930

    Nope only the exclusion part helped alot! Thank you! 

Unfiltered HTML