Eset License Login

[Vivien]

Wheni go to login to eset home security the url keeps looping with a callback?code and it just sits there and keeps doing it and not loading any pages. i saw this was and issue before anyone figure it out?

We have had a long standing issue with ESET and being able to login to sites or apps that use MS authentication. We have an internal application and our login to Office 365 fail to login. You try to sign in, enter the username and password, go to our federated server for the authentication and then get turned right back out to the network login. A few turns at doing that, and sooner or later we start locking accounts.

We ultimate figured out the issue was an issue between Windows 10 v. 1803 and ESET. Works fine up until we install ESET and then, once it's installed, we can't login any longer. I can't speak to the 1809 build but it definitely happens with 1803. We figured out a work-around until a patch comes along - we have to go into web access protection and disable http protocol checking and https checking. With those disable, everything works fine.

Any ideas why this is an issue or is there a patch in the works to address? I don't like having to do the work around obviously, but as we roll out more windows 10 machines and move more to office 365, it becomes a bigger issue.

If I am interpreting this right, you're trying to login to Office 365 through this internal application? If this is the case and alternatively, you can just exclude this internal app from Protocol filtering. This is much safer than totally disabling SSL protocol filtering. See the below screen shot:

I did go ahead and try the url, but that didn't work either. I also tried excluding the ip address of the page and tried to do what Peter suggested as best as I could understand it - by adding the site to the list of addresses to be excluded. That did not work either.

Looking at a bit more, I realized it's not the site per se, but the Microsoft authentication is uses to log users in that is getting hung up. I can also duplicate the behavior by trying to login to Office365 - click on login, enter credentials, the system tries to validate against our local federated server and then kicks the login back out as if it never happened.

That makes me think it's something in the validation process with our federated server that is causing the issue. But when I add the federated server url to the URL Address Manager, I still get the same behavior.

I can also duplicate the behavior by trying to login to Office365 - click on login, enter credentials, the system tries to validate against our local federated server and then kicks the login back out as if it never happened.

You need to navigate to ESET Advanced setup -> Web and email -> click on the Edit button next to the List of known certificates -> Add -> set the scan action to Ignore -> select URL next to Import certificate from URL can enter the URL of your company auth. URL. See the details on the attached screenshot. Please let us know if it helps.

I can say I have also seen this. It seems that the Apache server takes a few minutes to actually start listening even though the service is running. If it never connects then I would run a "netstat -aon > c:\ports.txt" in a elevated command prompt and send it to me in a PM. I will go through it and see if this a port issue. The other issue we are seeing is that Apache does not update the new path for Java when it updates. You need to update the path to the new Java Update by using this program found here:

C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\bin\Tomcat7w.exe

When you open the exe it will show you a path. Follow that path and you will see that Java changed the path for the new version. Simply copy and paste the new path into the dialog box replacing the old path ad click ok.

This is Server 2012 R2 running WSUS and DPM 2012 R2 and it used to host the ERA 5 server. I'll go install Microsoft Security Essentials and Defender back on all the workstations until you can figure out what this is.

I haven't seen the ERSServer crash more that the one time, but perhaps a feature request for ESET is to create a monitor service that checks if the required services are running and start them if needed.

I will say that I had the same issue yesterday. I restarted and the issue persisted. I ended up having to have ESET's escalation team repair my install on Windows 2012R2. They were unsure of the root cause and could only speculate that Windows updates was the issue.

We have decided to rely on system to restart service in case it stops unexpectedly. Main ERA components have support for both systemd and upstart (added in version 6.3) init daemons with enabled automatic restarting of services - which should cover most of mainstream linux distributions (including ERA appliance which was really missing this feature).

They were that day. But as I arrive back in the office today, I am having the same issue all over. This is twice in one week so I will have to take time out of my day as well as our Engineer's to get this fixed.

I experience this daily, but I am able to always easily resolve it. I haven't investigated the technological reason further, but I suspect that (in my case) it has something to do with the Apache server taking a little bit to start listening. I also tend to remove the previous URL because it is a path to the last location you were at in ERA -- I don't know if that correlates to the solution, but I have had the most success by navigating/refreshing back to the 'root' Web Console URL: localhost/era/webconsole, and logging in again. It resolves for me every time.

Just want to add that 2 of my clients ran into the same issue recently. Turns out the culprit is that Network.dll had not been properly upgraded. After running component upgrade from ERA 6.2 to 6.3, Network.dll is still 6.2 version, causing 6.3 service to crash. I took the dll from a working 6.3 installation, replaced it, and viola service starts working properly.

Thanks for including other workarounds here for this issue. Different network configurations as well as deployments (for instance, whether a clean install or upgrade) seem to affect the solution for each environment.

Since the version is same (6.3), network.dll won't be replaced during a repair. It's necessary to replace it manually. If you were installing ERA v6.4 (which is not available yet), upgrade would work and the dll would be replaced automatically.

A complete reinstall corrected the problem, until I changed ports again. I was pretty confident it was a port issue. I did not find this in any of the documentation I ran across, but I did note that the process to rebuild the era folder under the Tomcat directory requested a replacement of this file: C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\webapps\era\WEB-INF\classes\sk\eset\era\g2webconsole\server\modules\config\EraWebServerConfig.properties

More info: I was getting repeat logins when using the Eset Banking and Payment protection option to access my bank account. I have disabled the Banking protection option and I can now access my bank account with no problems.

Do you have the issue with logging in to my.eset.com even if you start Windows with networking in safe mode? Could you try uninstalling one of the browsers and installing it from scratch, ie. without using existing user profiles/settings?

Does the issue persist after uninstalling ESET?

5. Today, I uninstalled Eset and rebooted. Then installed Eset by downloading the latest version from Esets website. After rebooting and using the same browser as before (Firefox) I can now log into my.eset.

I've had Eset installed for a while (years) and have always allowed Eset to perform updates. So my thought is that something has changed between this version (14.1.20.0) and the previous version which only causes a problem when updating rather than doing a clean install. Just my thoughts...

This morning logging onto to my bank account via Esets secured browser, I encountered the same problems as before. I then tried logging onto myEset account but experienced the same problems as mentioned in the original post.

Greetings, I have just set up and configured my ESET PROTECT server using the virtual appliance I downloaded. However, when I tried logging on to the web console, I keep getting the error 'Login failed' (with no further details that follow such as invalid username or password, communication error etc). I'm absolutely certain my password was entered correctly, and have redeployed the appliance three times and have consistent results across all. I feel like I might have missed some kind of configuration. There are no firewall between the machines and they're all sitting in an isolated VLAN. I can logon to the appliance management console fine with the same password (i.e. changed from eraadmin). Can somebody help me please :))

3a8082e126