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

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,

Hi emmosophos,

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

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 alda,

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

Thats not entirely correct. 

The endpoint will extract both information (domain and samaccountname) and look for the matching domain (server) on XG. If there is no server, it will likely not find anything to authenticate. Moving towards this issue in this case, you could easily move all your ad servers to the .com address and reauthenticate all users. It should work for SSLVPN and for all HB authentications. You need to streamline the requests and only use the .com. It should work in that 

Thats not entirely correct. 

The endpoint will extract both information (domain and samaccountname) and look for the matching domain (server) on XG. If there is no server, it will likely not find anything to authenticate. Moving towards this issue in this case, you could easily move all your ad servers to the .com address and reauthenticate all users. It should work for SSLVPN and for all HB authentications. You need to streamline the requests and only use the .com. It should work in that 

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

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. 

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: 

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.