Heartbeat authentication failed : username without domain name maybe the cause- Live users disappear but still connected to vpn

Hello,

we use the SSLVPN authentication to apply different rules for users and the heartbeat to have the synced security.

Sometimes the user still connected to the VPN but not visible in the live user, in this case the rules with match known user not work! He need to reconnect the vpn to be visible again.

I found on the log a lot of error in the authentication tab related to heartbeat. All heartbeat have the status FAILED. 

If i compare with SSLVPN, the @domain is visible and the authentication work fine. 

For the problematic user, we can see the logout in the log but on the desktop ,the vpn still connected ! 

Any idea why the heartbeat doesn't return the domain? Could be the cause of my problem? Thank you



Edited and Added TAGs
[edited by: emmosophos at 12:38 AM (GMT -7) on 24 Apr 2021]
Parents Reply
  • Seems like this user cannot be authenticated vs any AD configured in XG. Compared to the SSLVPN authentication, do you see a difference? in the Domain or something like that. 

    __________________________________________________________________________________________________________________

Children
  • For SSLVPN i configured it in authentication/service and select all AD Server, for heartbeat i don't found any option to change or configure. I don't understand why it can't have a successful authentication it's the same user and same server. 

  • XG tries your username (SAMAccountname) and fires it against all AD server, you configured on XG. Seems like 3 different AD Server are configured. 

    It is important to notice the used domain on the XG in AD Servers. This will be attached and used against this AD server. Seems like this does not work. 

    Looking at SSLVPN, it looks like it uses a UPN (Accountname + domain + top level domain). 

    __________________________________________________________________________________________________________________

  • We have one domain with multiple subdomain it's why we have multiples AD servers. I need to use all AD in my case. It's working fine for SSL, why not for heartbeat? I assume that when you connect using sslvpn, XG will try all AD server..  

  • It seems like the user use the sub domain, which is not created on the XG? 

    __________________________________________________________________________________________________________________

  • Yes all user is created and work because it's a user who use the VPN, the authentication work, in  this case the user is created on the xg but i don't know why the username isn't recognized  ?! so strange 

  • Let me rephrase my point: 

    Endpoint extract the Username and the domain. 

    Sends it to XG.

    XG looks up the matching domain in the list of AD Servers. 

    Sends AD user name to the matching AD Servers. 

    The used domain on the endpoint could be different to the domains on the XG. 

    __________________________________________________________________________________________________________________

  • Ok but how can i specify the domain to use? I don't understand why when we make a ssl connection, we just type the username and sophos can found the good domain to use... 

  • Hello Julian,

    could you please answer the following questions and then I think I will able to tell you exactly where the problem is?

    - what is the name of the internal Microsoft Active Directory domain, I assume "domain.local"?
    - what is the value of the userPrincipalName (UPN) parameter for users of your internal Microsoft
       Active Directory domain for which Security Heartbeat does not work, I assume "domain.com"?
    - I assume you have these settings because you use Microsoft Teams, right?

    Regards

    alda

  • Hi ,

    i want to avoid to give some details of the organisation and i will replace it by "company"

    -what is the name of the internal Microsoft Active Directory domain : company.int

    - what is the value of the userPrincipalName (UPN) parameter for users of your internal Microsoft : @company.com

    -Active Directory domain for which Security Heartbeat does not work : Yes company.com

    - assume you have these settings because you use Microsoft Teams, right? Yes :)

  • Hello Julian,

    you confirmed to me what I expected. 

    The problem is in the value of the UPN parameter. If (for a test) you change the value of this parameter in an user account in your Microsoft Active directory to "user@company.int", the authorization for Security Heartbeat will miraculously work correctly. For SSL VPN remote access, the authorization will still also work, because for SSL VPN (what a surprise) the sAMAccountName is used, ie an user name in this case is "user@company.int".
    Sophos developers mistakenly assumed when developing Security Heartbeat that the value of the UPN parameter must match the name of the internal Microsoft Active Directory domain, ie in your case "company.int". This assumption, based on Sophos developers, is not mentioned anywhere in the Microsoft Active Directory documentation.
    On the contrary, their assumption, especially for medium and enterprise companies, does not correspond to reality.
    Unfortunately, another annoying consequence of this error in the development of Security Heartbeat is the inability to use Microsoft Teams and Security Heartbeat at the same time, because Microsoft Teams requires the use of the FQDN public domain name, in your case "company.com".
    The date for eliminating this problem, which we pointed out to Sophos almost two years ago, is still unknown. Although we have opened a support ticket for this problem, there is still no answer to this day.
    I apologize if I saddened you with this post, but in the current situation, do not assume that you will be able to use the solution according to your requirements.

    Regards

    alda