Thread Info
  • Locked Locked
  • Replies 12 replies
  • Subscribers 7 subscribers
  • Views 26684 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 issue with multiple DC's & collectors

Louis-M

Whilst testing STAS, we came across some anomaly's where not all users were getting logged.

The setup:

4 x DC's over 4 different sites. All DC's entered into the UTM under STAS with all DC's having the full STAS Suite installed and running.

All of the STAS collectors/agents were up and running and all tested. The reason the whole suite was installed is for resilience and failover eg incase 1 DC failed.

The Issue:

looking through the logs, the UTM only queried the first STAS/DC server in it's list. It did not work it's way down the list as we would have expected. Therefore, it would only log the authentications that were done on this DC. This resulted on authentications on the other STAS/DC servers being missed.

It appears that only if the connection fails to the first STAS/DC server in the list, that the next server will be tried for authentication.

The workaround:

Specify the first STAS/DC server in the STAS Collectors on each of the other servers.

This appeared to work and now all users are authenticated. It does however, still leave the question of if the first DC fails, who then becomes the collector?
I am going to add other collector IP's into the agents as Sophos state that only the first collector in the list gets the authentications so I am hoping that if that collector fails, it will try the next collector in the list and so forth.



This thread was automatically locked due to age.
Parents

  • Hi,

    I have earned some experience with stas and I know that sophos does not know 100%, how this product actually works. Last november I configured STAS for the first time, but never got it running as needed. Sophos says, "sorry in this moment the product does not meet your requirements". 

     

    My requirements, sorted by priority:

    1.) User/IP Adress Mapping on the utm is not part of cluster sync and doesn´t even survive a reboot. After a reboot the utm will have an empty user list. Most urgent problem--> not usable in a productive environment.
    2.) When using 2x STAS Suite, Users will appear on utm shortly after login event. But they will dissapear after 10minutes. It doesn´t matter, if logoff detection is enabled or not. There are very few users in the utm, while there are lots more active/logged in.
    3.) STAS Agent uses undocumented Port 50001. This can conflict with MS DNS Service random ports. There is a workarround, but not in the documentation. -->Very bad!
    4.) RDP session cannot be verified by wmi-detection, rdp users are not supported. RDP Users will initially appear in the collector list, but will then disappear
    5.) There is no full documentation, that fits totally the current behaviour of the software.

     

     

    But back to your question: I don´t know, how the failover/backup process works. I can imagine, that the utm decides which collector to use (perhaps based upon the collector list in utm?!). But you can test it, simply stop the STAS service and you will see, what happens then. With two collectors, you can observe, that the next collector will start to serve the utm.

    Does all of your "logged-in" Users stay in users authentication list on the utm? Did you configure Logoff detection? What are your settings? I could observe, that with full suites installed on more than 1 DC, the users appear on the utm only for a short time. Even when I configured the other STAS Collector in both Agents. The problem that I had with two suites installed was, that the users dissapeared from the users list after a certain time, even with logoff detection disabled.

    Then I removed the collector from one DC and the users list is now, as it should be. But... There a still all these bugs....

     

     

  • in reply to seroal

    Hi,

    my users do stay in the list. I have logoff detection enabled and set at 2 hours. It appears to work. Logons to our RDP servers are also showing.

    I agree that it is a little random as is my post above. I'm not sure how the UTM selects what STAS it wants. I would have thought it would go on the order of the list in the UTM, work it's way down when STAS fails and constantly poll the failed one until it comes back online at which time it would switch back.

    Documentation not great by any standards either and the whole thing does seem a little hickledy pickeldy to me too. I'll keep plodding on. Maybe 9.5 will have the improvements?

  • in reply to Louis-M

    Hi,

     

    Louis-M said:

    my users do stay in the list. I have logoff detection enabled and set at 2 hours. It appears to work. Logons to our RDP servers are also showing.

     

     

    Interesting. Whats your Detection Interval? Does your RDP sessions (assuming, that they are still active and no logoff has taken place)  stay active, longer than the detection interval? Did you monitor this for a specific user? Im asking because in my installation, rdp users will vanish after the the detection takes place. That behaviour fits to the official sophos statement:

     

    This is a answer regarding RDP from a sophos 3rd level engineer:

     

    3. Are RDP sessions supported? Should users connecting via RDP get authenticated and how do they get de-authenticated.
    Configured logoff detection seems to log off the users after the Configured time. It seems the workstation polling doesn't work for RDP sessions.
    Is this the case or not?

    RDP sessions are not supported. I tested this locally. This could be an improvement for STAS v3. Reason is that the collector basially uses a WMI query.

     

    Regards

    Sebastian

  • in reply to seroal

    There are also some open Tickets for this topic:

     

    NUTM-7045  Design questions about STAS
    NUTM-7447 [STAS] user list differs from the expected list of users as shown on the collector. 

Reply Children
  • in reply to seroal

    You are quite right. As our users came back today, I could look at it a bit more.

    1. We do have users that are in the UTM list from yesterday logged onto one of our RDP servers

    2. The list does not match up at all with the current sessions or idle sessions on the RDP server

    So, very hit and miss.

Unfiltered HTML