Heartbeat using wrong username

Heartbeat (on endpoint) does a checkup on the format of your username. It checks, if the SAMAccountname and Domain name differentes from the UPN. If case, it is different, it sends only the SAMAccountname to the Firewall. Then the firewall will match it against all AD Servers. Check your AD and this particular user. You find under Advanced View the SAMAccountname. 

yea, sAMAccountName is really in this format. Now the question is, how to handle this situation. Dont really want to change this variable in AD, it might breake some other service outside of Sophos stuff.

And why is Hearthbeat green, when almost every user failing to log in with HB?

Heartbeat is not User Authentication. Heartbeat is "Service of Endpoint is ok". The endpoint is doing his part and send the authentication. The firewall is just not able to authenticate. This is not a reason to change the heartbeat. 

You can fix this on the firewall. You can create another AD Server on the firewall and using the other Domain name. By doing this approach, the firewall will be able to authenticate with the other domain name, which is likely missing currently. 

SFOS blocks the creation of another AD server with the same IP. So to have the option to create another AD Server on SFOS with the same IP, create a FQDN Host on the firewall, call it "AD1" and point to the AD Server IP. You can use in Authentication - Server this AD1 and create it with the "other domain name". This should resolve your issue. 

well, this might work, if failing login would be in domain format but as you can see its just plain user.name without domain suffix.

Because the firewall cannot locate a AD Server to authenticate this user. 

Because the firewall cannot locate a AD Server to authenticate this user. 

not sure if we fully understand each other. Users should be authenticated by the currently added server (and they are successfully in other services other then HB). Its local domain in format *.*.cz

problem is that HB using sAMAccountname (which is without domain suffix) and firewall expecting login with domain suffix. This cant be solved by adding another AD server, right?

Can i somehow config firewall to it would expect sAMAccountname or on the other hand config HB to send some other AD attribute to authenticate?

Thank you!

The firewall will forward the SAMAccountname and attach the Domain, you configured on the AD Server to the AD Server. This result in a mismatch and the AD Server will give a denied back (you see this in the logviewer). The Logviewer will not show the entire logging request, but its domain\samaccountname

Hello Jakub,

please send to me PM and I'll let you know what the problem is. We solved a similar problem more than three years ago and did not solve it. The problem is not on our side, believe me ....

Regards

alda

I do not think, its the same issue. Simply create the additional AD Server and your issue should be resolved. The Installation of Alda is a bigger installation with duplicated user IDs in different domains. Likely this is not the case here. 

Hello LuCar Toni,

I think we both know very well where the problem is and it doesn't matter how many duplicated user IDs are in different domains.
The problem is in the Sophos implementation, where Security Heartbeat is in principle unusable for internal domains in the form "domain.local". This is also the conclusion of Sophos developers, I hope you do not contradict their statements?

Regards

alda

Jakub Kavka Feel free to give feedback back, if my approach resolved this issue. 

alda We discussed your setup multiple times. Its a issue of multiple users with the same name in different domains. This is a limitation of the implementation of SFOS, as it cannot differentiate between the Users and the first AD will report a success. 

Hello Lucar Toni,

Yes, even this is a limitation in the Sophos implementation of the Sophos Heartbeat as well. But there are other and absolutely fundamental limitations if an internal domain in the form of "domain.local" is used (which is still the format recommended by Microsoft for internal domains) and at the same time the format "domain.cz" is used for external communication (for Jakub Kavka environment, I think).
I feel that the limitations in implementing Sophos Heartbeat are unacceptably many.

Regards

alda

That is not the issue in this case. And the limitation you are talking about is not about .local domain. Its about the UPN vs SAMAccount name. But i will not discuss this again. 

Hello LuCar Toni,

it's a shame you don't want to discuss it again. But overall, I understand your position because you do not want to discuss the functional limitations in the implementation of Sophos Heartbeat.
But I have to fairly agree that the problem is in UPN vs. SAMAccount. But again, if the internal domain is domain.local and your internal users from this internal domain need to use for example the Microsoft Teams, you HAVE TO change the UPN name for all users from domain@local to, for example, domain@cz and this is the limitation I have from the beginning on my mind.

if I remember correctly, did Sophos a KB publish in this case?

Regards

alda

That is not correct. 

Heartbeat is working perfectly fine with a .local account.