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
  • Hello Julian,

    Thank you for contacting the Sophos Community.

    What do you see in the /log/access_log.log for this user?

    For the SSL VPN you’re using two different types of authentication? 

    As a suggestion, if you’re using Heartbeat and STAS for authentication, try to stick to only one type of authentication for the same segment of devices.

    Regards,


     
    Emmanuel (EmmoSophos)
    Community Support Engineer | Sophos Technical Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • Hi ,

    I need to wait the next event to check in access&***;log, i will check today.

    For VPN no we just use the AD authentication but when a user is connected using ssl, the authentication is SSL VPN but thought the AD. Some rules are created by using users

    To avoid to have 2 authentication with STAS and SSLVPN for the same IP i added the subnet of the SSLVPN to the excluse subnet in STAS. 

    But i have a lot of error for heartbeat in authentication TAB, for me i don't have any problem to use only the heartbeat for authentication of this user but how can i solve the error with heartbeat authentication? Why there is a lot of error? (Only error, never it's ok for heartbeat)

    Thank you

  • Hello LuCar Toni,

    believe me what I wrote is true. You can easily verify it yourself!
    As I wrote, all you have to do is change the UPN parameter and Security Hearbeat will work correctly.
    As Julian wrote the authorization to Microsoft Active Directory works correctly for him, the problem is in a different than expected value of the UPN parameter. The problem is not in the unavailability of the authorization server as you wrote. Just change the UPN parameter, that's the whole problem ....
    And to your recommendation to change the name of the internal domain, have you ever done something like that? And you know what all this will to do, especially if it's in Microsoft Active Directory Exchange Server, really? I'm sorry, but here it's called the road to hell ...

    Regards

    alda

    P.S. I apologize for the somewhat expressive sentences, but we have been facing this problem (as I have already written) for almost two years and no one wants to solve this problem. This problem is clearly in the implementation of Security Heartbeat.
    If anyone in the community wants more details please send a PM or I will have a ban again....

  • If i think correct, username was created before the upn have change. If i delete the user in the XG, it will be re created with the good upn? Have i to use the PURGE AD USER button? I never used it

  • Ok i have a better understanding. Thank you very munch for your explanation... Not a good news. In this case, can we stop the tries of sophos heartbeat ? Actually i only use the heartbeat for sync security (only green to access and present). I have sometime a computer red in the XG and green in central, i don't understand why.. 

  • I deleted a test user with @company.int and changed in authentication server for the specific ad in the field "domain name" i wrote @company.com and now i made a new connection using the portal and now the name is correct! I need other checks to verify if the authentication using heartbeat work... 

  • I confirm it's working !!

    In this case i need to recreate all user account... Not a good news lol i have some rules with specific users. I changed in AD the field domain name and now i think all users will create a new account. 

  • Hello Julian,

    please answer to one question for me and others: I assume you changed the UPN name, right?

    Regards

    alda

  • Most customers, i know of, already changed the internal domain because they moved to a public domain (azure AD migration). Hence they are using a single domain and therefore the login works fine, if you change the primary domain on the windows end.

    XG will create a User account for each domain, as those user are separate from each other, but it should work after all with a streamlined AD. Sure there are limitations in case of old ADs which are grown in bigger impacts. 

    And what you are display is true and confirmed to be the behavior. I still do not see the issue, if you upgrade your setup to a proper setup, it should not impact the network. 

    Even the Exchange end, this should work with powershell scripts. 

    __________________________________________________________________________________________________________________

  • The UPN was change several months when we integrate to O365 for Teams. The AD configuration in the firewall was configure with @company.com 2 years ago. I just changed the domain name field in the AD configuration, now a new user  was created in Sophos and the authentication with heartbeat works. Thank :)

  • Hello LuCar Toni,

    I'm very sorry again I could not agree. It is not possible to change the host name on the on-premise Exchange server and it is no longer possible to change the domain name at all. Microsoft does not strictly recommend this operation.

    Regards

    alda

  • Thats not my point. As we see in this example, customers need to change the top level domain. 

    Customers move from .local to .com. Users are logging in into the user namens with "domain.com". 

    The endpoint extract this user (as samaccountname) and the domain (as domain.com). Both information are send to the XG.

    XG looks up all the configured AD Servers for the domain name. 

    This is the important field in XG: 

    __________________________________________________________________________________________________________________

Reply
  • Thats not my point. As we see in this example, customers need to change the top level domain. 

    Customers move from .local to .com. Users are logging in into the user namens with "domain.com". 

    The endpoint extract this user (as samaccountname) and the domain (as domain.com). Both information are send to the XG.

    XG looks up all the configured AD Servers for the domain name. 

    This is the important field in XG: 

    __________________________________________________________________________________________________________________

Children
  • I can definitely confirm LuCar Toni's suggestion. Changing the field "Domain name" to the external domain is working for us. It should be noted that all user accounts have been newly created automatically. That of course leads to that all users have to create a new OTP and some user special configurations were lost.