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. 

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

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. 

Hello LuCar Toni,

You are well aware that this is not true and that the implementation of Sophos Heartbeat has major implementation limitations!
I end up discussing in this thread, discussing with you is just a waste of time.

How long will my last post exist before you delete it or block my access to this forum?

Regards

alda

Just to recap. You are mixing two different parts. The limitation is simply a UPN vs SAMAccount name issue. The limitation is not in the heartbeat, instead in the access_server (underlying daemon for authentication). 

This kind of issue comes up on regular basis and most cases get resolved by using two different AD servers. 

Your Issue (alda) is simply the problem about UPN vs SAMAccountname. The firewall matches SAMAccountname vs all AD Servers. If you have multiple users with the same username (user@domain.local and another user: user@customer.com), the firewall will match those users against the first user and will not be able to split them up. As we use SAMaccountname vs the first domain, we can reach. 

The limitation could be lifted by introducing a UPN filter. Which means, the firewall would only query the server, which uses the UPN. But this is not the case and will cause your issue.

But most customers simply have multiple Domains, but the same users. So user@domain.local and user@customer.com is the same user. And the EP will fetch both information, notice the difference between UPN and SAMAccountname, split both information and send them to the firewall. The firewall is looking for user@customer.com, but there is no customer.com configured. Therefore the authentication will fail. 

Hello LuCar Toni,

I wrote that I will no longer communicate in this thread and I will therefore limit myself to simply stating the facts:

- You are intentionally using a twisted scenario that does not match the scenario I have been pointing out from the beginning.
- I could post your own statements in this forum which confirm my statements, including your recommendations on how to work around the problem of poor implementation of Sophos Heartbeat, including your recommendation to rename the internal domain ...
- I could post to this forum all internal communication between me and my colleague and Sophos developers who will again confirm all my claims.

Please don't provoke me. That's exactly all from me in this thread.

Regards

alda

Lets see, if my approach will resolve the issue for the customer.