This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

STAS WMI Access Denied after Windows Update

Hello all,


We are facing several problems with STAS Logoff detection method - WMI after the lasted Windows updates mid of June.
All computers are returned Access Denied when we execute WMI test over STAS. This is causing a big problem with discnnection users.

Is there any Sophos Staff or someone that has the solution for this ?

We already try change several Regedit entries, but without sucess.

Regards

Carlos



This thread was automatically locked due to age.
Parents Reply Children
  • It is currently not clear, if this is actually the issue. 

    We did some testing, our STAS works fine with a currently patched Windows Server/Client. So we are not sure, if MS patches all the systems at once or not. 

    Do you see those Event Log errors within this KB? https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c

    __________________________________________________________________________________________________________________

  • I also tried to reproduce this issue today and found that STAS WMI polling continued to work fine after updating Windows 10 Workstation and Windows 2019 Server to the latest versions, and enabling the Microsoft registry key (i.e. setting the value to '1' which is supposed to force the new authentication level requirements).

    Perhaps some other permission or rights setting to allow WMI to work is being changed when these devices apply updates in your environment. Have you re-checked the usual things, such as necessary permissions to the WMI Control service (in Computer Management -> Services and Applications) on the workstations, and confirmed that the account that STAS is using to log in, is still correctly included in those permissions, and that the DCOM options in Local Security Policy/Security Options have the correct permissions, and the Windows Firewall is not blocking the access.