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
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…
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.
please answer to one question for me and others: I assume you changed the UPN name, right?
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 LuCar Toni :)
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.
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:
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.