Thread Info
  • State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 8889 views
  • Users 0 members are here
Options
Suggested
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 Logoff Detection & RDP

Patrick Hindall

Since the implementation of STAS SSO, we’ve had a problem with users being logged out of the firewall (logged out of STAS) when the user is connected to their workstation via RDP.  Note, when the user is connected directly to the console of their workstation machine, STAS works beautifully.

The cause is easy to figure out, but the answer is not.  I’m wondering what the short-term solution is, and if the knuckleheads at Sophos have ever thought about a better way to do logoff detection?  Like the Sophos recommendations suggest, we have enabled STAS Logoff Detection with workstation polling using WMI.  It is widely known that WMI will not report the current user who is logged on to a workstation via RDP.  WMI will only report the current user logged in via the machine console.  Hence, while RDP users initially authenticate with the firewall via STAS, after the detection polling interval, they are “logged out.”

Our environment is comprised of workstations which can be accessed locally or remotely via RD Gateway and RDP.  Note, these are single-interactive-session Windows workstations, not multi-user RDP terminal servers.  This setup is not unusual, which leads me to believe someone, somewhere has come across this.  So, what should we do, and what are the ramifications of each?

  1. Turn off Logoff Detection. Do I really care whether STAS detects logoffs?  We do have several “community use” workstations, where many different users log on and off throughout the day.  It is imperative that AD User & Group based firewall policies be applied correctly to the currently logged on user.  At present, this is working correctly, but I fear turning off Logoff Detection might make this less reliable.
  2. Change the Workstation Polling method to Registry Read Access. I understand that this method requires turning on the remote registry service on the workstations (which is a pain in the ass).  And, assuming running the Remote Registry service doesn’t present some unforeseen security risk, I’m not even sure it will solve the problem.  Will the Registry Read Access polling method identify a user logged on via RDP?
  3. Wait for Sophos to find a better way to do logoff detection.
  4. Find a better firewall vendor.


This thread was automatically locked due to age.
Parents
  • 0

    Hello Patrick,

    I have encountered the same problem you describe and found the only possible solution that, unfortunately, was not 100% reliable too - Sophos Authorization Client. Users were mostly dissatisfied with changing their passwords - they had to paste their new password for authorization to this client.

    But from v17.5 I have solved this problem, I started use the Security Heartbeat and Central clients and this solution does not suffer from this problem ....

    Regards

    alda

  • +1 in reply to alda

    Please see below:

    You must specify IP address of any RDS session host...

  • 0 in reply to GabrieleD

    I do have my RDS Session Hosts IP addresses exempted from STAS, as suggested.  But, to be clear, the problem is not with RDS Session Hosts.  It is with traditional single-user, single-session Windows 10 workstations.  Like any traditional workstation, these do participate in STAS and do not run the SATC client like an RDS Session Host server.  It just so happens that users can and will access their traditional workstation remotely via RDP.  And as stated, WMI does not report the current user of a workstation logged on via RDP.  Thus, log-off detection using WMI polling does not work for users logged into a workstation via RDP.  The real answer was to forgo using WMI polling for log-off detection and to use Registry Read Access instead.  Then, we had to enable the Remote Registry Service on all our workstations (this was easily done via Group Policy).  Now log-off detection works regardless of whether a user logs into the console of their workstation or accesses their workstation remotely via RDP.

  • 0 in reply to Patrick Hindall

    In this situation when a user logon to remote PC via RDP, it's same thing when user logon into Terminal Server.. you need treat those PCs as if they were terminal servers.

    I have no similar situations to your, however I would be curious to understand how firewall see users.... (with WMI and then with Registry Read).

    If the User1 logs on to PC01 assume the firewall sees User1 associated with the IP of the PC01.
    If the User1 from PC01 makes an RDS connection to the PC02 using the same credentials: I would be curious to understand what the firewall detects:

    User1 associated with the IP of PC02 (with WMI)
    User1 associated with both IPs (with Regitry access)

     

    Thanks

Reply
  • 0 in reply to Patrick Hindall

    In this situation when a user logon to remote PC via RDP, it's same thing when user logon into Terminal Server.. you need treat those PCs as if they were terminal servers.

    I have no similar situations to your, however I would be curious to understand how firewall see users.... (with WMI and then with Registry Read).

    If the User1 logs on to PC01 assume the firewall sees User1 associated with the IP of the PC01.
    If the User1 from PC01 makes an RDS connection to the PC02 using the same credentials: I would be curious to understand what the firewall detects:

    User1 associated with the IP of PC02 (with WMI)
    User1 associated with both IPs (with Regitry access)

     

    Thanks

Children
No Data