STAS issue with multiple DC's & collectors

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

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?

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

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. 

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.

I've tinkered only a bit with STAS, but I can say it's still rather unpredictable and borderline unusable at the moment. For example, I have an entry on my "Online Users" list that shows:

Noticed the "Active Directory Users"? For some reason this user is being mapped as this, instead of the username. For the life of me I cannot get this specific user to map to it's IP address. STAS and aua.log show the user is correctly mapped to it's IP address, but WebAdmin just won't reflect this. Go figure.

Anyhow, I've hit the same pitfalls as you. Multiple STAS working as collectors and reporting their entries to one another showed unpredictable results to me. I ended up having to use a single collector and agents on the other DCs. Since trere's no documentation whatsoever that tells us what we can and cannot do (even from Cyberoam, that it's from STAS is originally from), it's been a lot of hit an miss. And I do agree that if you have a high available environment with two or more DCs STAS should be able to run on a high available multiple collectors setup, and allowing collectors to act as collectors and agents ate the same time would be a neat way of doing so. But it does not appear to work, at least it wasn't a few months back when I got similar results as yours. Based on Louis report, however, it appears that this might have changed. I'll try to test it again next week. 

As for RDP, STAS is not the tool for this. You see, STAS maps an user to an IP address based on login entries from DCs. On a RDP server you have multiple users sharing the same IP, so STAS goes haywire. If another user logs in using the same IP as another logged in user, STAS appears to just delete both entries. Sophos does have an solution for this called SATC, but it appears that it's only available to XG and have not been ported to UTM yet. Considering they ported STAS, SATC should be in the roadmap.

As a workaround you would need to create a "regular" Web Protection profile using Standard or Transparent mode with AD SSO authentication exclusively matching your RDS server IP address and place it above the profile using STAS. That way remote users accessing your environment through RDS would be authenticated using SSO, as the profile would be restricted to your RDS server IP address and would be matched before the STAS profile, and everyone else would be authenticated using STAS.

Regards - Giovani

Out of interest, is there any log on the UTM for SSO authentications? I can't see it.

For STAS you can check aua.log for events with caller="stas". Those would log any logins passed to the UTM by by STAS. For SSO I don't think there are any logs as the authentication is merely relayed by the UTM to the DCs. 

For STAS you can check aua.log for events with caller="stas". Those would log any logins passed to the UTM by by STAS. For SSO I don't think there are any logs as the authentication is merely relayed by the UTM to the DCs. 

I like the STAS logs in the UTM and the list of users. It's a pity AD authentication didn't have something similar. Even better would be a table with the option to block a currently authenticated user ie automatically drop them into an overarching block rule if required.