Guest User!

You are not Sophos Staff.

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

Authentication Restrictions - Multiple Users

Hello!

Is anyone aware of any danger of having the same user logged into multiple computers at the same time when implementing Heartbeat Authentication and NTLM?

Take this as an example;

We have 2 computers and one Sophos XG. All setup with SSO to an Active Directory which works perfectly fine.

We have 2 authentication servers on the Sophos XG to two separate AD's. This is because we utilize two UPN's in our domain, so some users have a UPN of "@CompanyOne.com" and some users have a UPN of "@CompanyTwo.com".

Both of these computers have Sophos AV installed and both of the computers, when logged into - appear on the Sophos XG with the correct UPN and the correct authentication method "Heartbeat". It should be known at this point, NTLM authentication or better known in Version 18 as "AD SSO" is enabled and used as a fallback when heartbeat has a problem or the client doesn't have Sophos AV.

My issue is this;

Computer 1 logs in at 09:30 AM. They login as "User1@companyone.com" and this appears on authentication as "heartbeat" with the Sophos XG.

Computer 1 continues to browse, listen to internet radio and generally "do stuff" until 10:30 AM. They go and make a cup of tea.

Computer 2 logs in at 10:35 AM. They login as "User1@companyone.com" and this again appears fine on the Sophos XG.

Computer 2 is browsing, having a whale of a time.

Computer 1, the user returns to the workstation and find his internet radio stream has stopped. He loads up "bleepingcomputer.com" and find they are redirected for ntlmauth. 

The Sophos XG logs, at the time of the problem shows that the client should be authenticated. But the issue occurs after a login on Computer 2.

I can't find any documentation to state there is a limitation on how many PC's a single user can login to.

And on the other hand, there was a bug in SFOS 17.5.7 where a user will be prompted for NTLM when they're actively logged in using Heartbeat - this was patched in SFOS 17.5.9. We're now on 18.0.4. We've been assured in the past that bugs do not return in later Firmware versions by Sophos rep's because of the testing procedure they use in house. So is there an issue with my setup?



This thread was automatically locked due to age.
  • Do you have to mix Heartbeat with AD SSO (NTLM) ? The point is, everything feeds into the access_server. And NTLM/kerberos is more or less a standalone tool to use. Thats my take away, if the customer uses Sophos Endpoint, there should be no reason to fallback to NTLM.

    But anyway: Your issue seems to be related to the HSTS issue. I discussed this topic here in more detail: https://community.sophos.com/xg-firewall/f/discussions/118573/set-up-kerberos-in-v18/451140#451140

    Basically the client is trying to connect to the 8091 redirect via HTTPs but NTLM need HTTP to work. 

  • Afternoon.

    I do believe this client has some devices which are not covered by Sophos Anti-Virus, thus the need for NTLM fall-back does exist.

    Also, for the odd times in the year when Heartbeat has a problem on Sophos' end (which occurred twice last year) all clients are then unauthenticated with no automatic way to "failover" to an alternative method.

    The main takeaway here I believe is that there isn't any documentation from Sophos officially which states "use one authentication method only". Even when doing Sophos XG training in Oxford I was instructed that Authentication will occur in XYZ order, with the only two which you shouldn't mix are Heartbeat and STAS. The fault we're seeing above is that we're being directed for NTLM, when the user is actively authenticated with Heartbeat - so why are they getting redirected to :8091 in the first place when the firewall already knows who they are - whether or not the request hangs due to HSTS.

  • That statement was simply my personal preferences. There are pros and cons to have such a mechanism (If this IP is already authenticated, do not "overwrite"). 

    The point is, all modules like heartbeat and NASM feed the access_server with information. This service is the central way to handle the authentication. It will overwrite each request with new information. 

    Your user is authenticated by user A via UserID. NASM gets a new information for this IP and User B. It will pass this information to access_server and this module will overwrite the IP to User mapping and change the user from A to B. 

    Its not that simply to say "if this user is already authenticated, please ignore everything else". There are certain deployment, which require a overwrite. 

    Thats the reason to split up this scenario and think about which zone needs which authentication.

    Generally speaking: To mix protected devices with "non protected devices" (anything without AV) is bad practice. We are advertising for years to start to segment the network. Lateral movement is a crucial element of attacks (see MITRE Attack framework).