avielc

Thanks for replying foneil - Does it mean its known and will be corrected?

Yes, exactly that. When I edit the task to change a target computer (E.g. agent deployment) If I want to run the task with a new computer as a target, I must write the password again. That wasn't the case on ERA 6.0-6.5. I couldn't see or show the password written, but at least I didn't have to re-enter it every time I add a new computer to the domain.

Maybe I don't understand well enough how packaging and creating an agent works. But Ubuntu was released back on April 2018. You're saying You would (and without guarantee) try to get it patched by mid-2019?? Michal, I'm sorry, but this is most displeasing and appalling to hear. All you need to do is add a simple check for a libssl-dev package and correct it if needed. That's it. - I know this is barely scratching the surface and there may be more to it than just apt-get remove libssl-dev:amd64 and maybe there would be major concerns on other unix operating systems that weren't reported yet. But I would expect a quick solution for such an issue that is reflected on all latest (and LTS based) Operating system of a major distribution as Ubuntu. Can't you ask to prioritize\promote a quick hotfix for the Linux agent? Thanks again for all the help over time here, and replies, I appreciate it, even if current request comes from a displeased position as a customer and as a low level experienced in Linux, IT engineer.

So yea, that's pretty straight forward I just noticed the server tasks for agent deployment aren't saving passwords at all. What's up with that? this is kind of a set back.

Ok, great! But still, I will need to do an apt-get remove run for every machine I install in the organization, that's a great workaround but not a proper solution, can everyone have a proper,valid,official solution in the form of a new installation package? Thanks for pointing it out by the way.

You're missing the point @Rami - the quote of apt-get remove was to show what is being done by removing that libssl My main concern in removing \ downgrading \ installing earlier version of openssl (what is being actually reported by ERA) is that it would cause conflicts with the Ubuntu18.04 Now, In U1804 it seems there is no "earlier version" for openssl, BUT! for that libssl-dev library there seems there is, and that's why it "feels" safer and less "dangerous" to actually remove it. Again, Hoping for a proper fix from ESET in the matter.

Thats what i'm saying @MartinK - it's not an option on Ubuntu18.04 as there is no old package called OpenSSL 1.0.X - so you can't install "old openssl 1.0.X version" However this solution mentioned actually helped, it removed only the library responsible for dev-ssl usage, while installing an old variation of it automatically. Which I believe that libssl-dev is relevant for ESET. Perhaps you can use it and add it to the agent package?

I think it'll be best to answer with the quote of what the apt-get remove does: put it simply - the apt-get detects the removal and installs a new package of the same kind but I guess older version which works with the agent (so you don't need to mess with the openssl main library) Now if only ESET were to add such ability into their package, that would've been grand.

So Someone posted an apt-get command that helped. I have to say it was a swift and somewhat made me feel "safe" running it. Command is : apt-get remove libssl-dev:amd64 Thread where solution was found : Here It was for Debian, it works on Ubuntu1804 while removing libssl-dev it installed a different older version (which is a good thing I guess) So it seemed good enough for now, I would still like to hear from any Dev, or anyone else that can enlighten the topic a little more, possibly offer a better solution in order to avoid such removal on every U1804 computer.

Somehow I don't understand how no one mentioned it. I've run into an old post about that issue, couldn't find proper solution though, Can anyone direct me to an answer? This is the log of installing the new ERA agent on an Ubuntu 18.04 which still keeps failing. I did run into a post like that, but can't figure out what's the solution or path for solution: Previous Archived post from the forum. From what I understand OpenSSL 1.1.0 won't be acceptable, but Ubuntu 1804 comes out of the box with that. Hoping someone can assist as this is an issue.

Thanks Peter, Any information regarding on the usage of 2FA on a Mac that is under Active Directory environment? Will there be any issues with the user? or will it display as usual an OTP popup for the 2FA? Do I need to setup anything on the Mac to make it work? Thanks

Hi Everyone (This is intended to staff as well as any members in this forum that can share their experience with the product I'm interested in the 2FA solution for Active Directory, however I have a mixed environment of Windows and Mac OS X platforms, Will 2FA work for both these environments? Thanks Aviel

Thanks Macros! looking forward to it

Hi everyone, I have a few users specifically in Mac environment that either they deliberately quit the ESET app from running or the app crashes from time to time. Is there any way to create a trigger that whenever an app is detected not to be running it'll be auto started? If so, Could you direct me to the instructions for it? (Will just save me some time digging through the admin guide.) Thanks

Ouuuu Nice @Marcos! When will the new ESET v7 will be out?

This has came up before but I still have some issue with it, and I'd like some clarification and assistance if possible. I'd like to setup a firewall policy for our users, however from trial and testing, it seems that when I try to apply a certain rule it'll lock the firewall AND disallow anyone to permit a certain function should it not fall under the firewall category. A find example would be Allowing Docker to pass through, for some reason only a certain rule accepted Docker pass and nothing else did. (I had to allow a certain port in.) Can I create a rule or a zone that is free of firewall limits inside the organization, while allowing users to adjust the rules should they need to when outside the organization? Thanks.

@bbahes - Thanks for that mate, I meant securing the communication between ERA and the clients\agents. whether some official document that mentions hacking such port entry isn't possible because This or That... Etc.... or by saying, as you mentioned certificates which filter the communication and avoid any kind of DDOS and such, Some details to assure it's ok to use it, would be most welcome. Thanks!

Hi All, I'm looking for different kinds of answers to this question (I'll be asking it at the end of my explanation). Here are a few kinds of answers I'd like to hear: - Anyone who found a solution for the security concern of the matter (aka deployment of a firewall\filtering system for accepting information from external toward the server) - Any direction to the security level ESET is following by to understand risks or no risks in exposing ports from an internal server to the world to allow agents to connect. - Any other idea on the matter really. The Question: Put it simply, I have a few employees who aren't accessing the office network on regular basis, I'd like to make sure their ESET Agents will still report in when possible, and exposing ports to the WAN side of the organization is somewhat a concern, so I'd like some peace of mind on the matter. if anyone can help, that would be really really helpful. Thanks all!

Hi Martin, I'm trying to do it on all computers and it doesn't seem to do anything Doesn't affect any kind of update, either hotfix Windows update pushes, or Windows defender updates which also arrive through Windows 10. Any thoughts what could be the cause? or How I can diagnose it with the agent?

I've tried both with the Automatic accept EULA, and its not working.

Same Issue here, Just ran into it now. Running latest Windows 10 Pro 1703 Creators Update, And EES 6.6.2052.0. Update doesn't occur and the task finishes successfully (I checked Optional and normal updates just unchecked automatic restart. Any ideas?

Anyone who follows this topic should be aware. There is a new thread with a solution issue is related to the policy that touches the Maximum definition database age. if its turned off it'll be a problem, but otherwise it'll rectify(correct) the issue

@MichalJ @Peter Randziak Just letting you both know. This is the same issue I've been seen on my side where ESET 6.5.2107 hasn't fixed. I have tested that Maximum Age thing. It has successfully resolved it. but As @fxcd said. This is definitely a bug that shouldn't have occurred. Thank you all for sharing the information @fxcd - Especially thanks for bringing it up again, as I was starting to wonder what happened to my request, and your detailed info helped me find that setting in our policy

Sent it to you via message Waiting to hear back from you

Answering inside the message