That works for us :)
Thank you for this post! This solved my issues!!
The procedure to fix 2FA did not work for us.
We see the Authanvil module menu (only the configure authanvil settings), configured it to localhost, disabled is checked as advised.
QR code is asked to a user logging in and it is successfully recognized by the authenticator (both Google and Microsoft show the same OTP) but when this is entered in the login screen it is always invalid.
After few attempts the user gets locked out.
Opened a ticket with kaseya.
Just as a warning for others applying the patch at later stage it may cripple your on premise installation.
For us, now we still have time until 1/1/2020 so support has some time to remedy our system.
There should be at least an option to setup something in the system to ignore 2FA and not lock yourself out.
Alessandro Di Marco
While it is HIGHLY NOT RECOMMENDED, you could setup your system logon policy to not lock out a user and not require 2FA.
System > System Management > Logon Policy.
Thanks, but all of our users have already the "Required" unchecked.
Nevertheless the login keeps warning the user to register for 2FA and that it will become mandatory.
If one does not turn the option on, the warning should go away in my opinion
I tried restarting Kaseya to see if the 2FA would be fixed that way but the result is worse.
All my Kaseya menu are now duplicated... (I see 2 icons of every single option).
In addition most agents are not updating to 184.108.40.206.
I will create 2 more tickets. Very difficult to work with this new version.
I am happy others had surely a flawless update but this is for us the first time in the last series of patches having so many issues,
Especially because we are generally cautious and update only when other confirm all is good.
The module issue is likely in relation to a funclist (internal function) to display modules. Creating a ticket should resolve this for you and your team.
All environments are different; I have incurred some 'oddball' issues during upgrades myself.
As a company, security is our #1 focus as we highly encourage our users to utilize 2FA whether through AuthAnvil or a medium of your choice. I can understand the nag being a bit redundant; we are likely going to make an announcement regarding VSA and user security regarding Two Factor Authentication.
Sure, hopefully the support team will resolve the issue.
I have created the ticket and just went through the whole usual Level 1 check list and now waiting for L2 support to come in.
Nagging is okay I am more concerned with the fact it says it will become mandatory (despite internal settings this is not required).
We survived without 2FA for long enough, even if support takes 2 years to resolve this issue I am okay (as long as we are not getting locked out from the system while we wait).
https://<url>/dl.asp is still not https enforced.
I've been trying to setup the new 2FA functionality since I did the .24 update last week. My experience, after having locked my account out, is that it just doesn't work.
We don't have and have never had AuthAnvil, so the fix mentioned earlier relating to AuthAnvil is not applicable.
I have only had the system accept an authorization code from an Authenticator once, all subsequent attempts have started the enrolment process, successfully setup the account in either Microsoft or Google Authenticator, but then just errored when entering the provided code in the login dialog.
Error: "We could not validate the Authorization code provided, please try again."
I've logged a support ticket tonight.
I certainly hope the notice about it becoming mandatory at the end of the month is not correct....
2FA has worked fine for us, and I understand its been no problem for other users (different VSA installs) speak with regularly
Support should be able to resolve your issue.
It appears that there is a bug related to remembering the devices which bypasses the need to manually enter the code each time you log in.
If the device is allowed to expire the login goes into an infinite loop where it will fail to let the user log in but it will also not prompt for a new key from the device.
I resolved that problem by disabling the remembering of devices so users are prompted every time for the key shown in the authenticator.
Good thing I had a backup master admin account when I found this or I'd have been locked out.
Craig Hart is correct. I recommend these functions go through support to ensure you have the proper fix on your server.
So, an update on my 2FA issues, Support seemed to have a pretty good idea as to the cause, their first question was "Are you in the same timezone as the VSA?". For me, the answer is no.
So the test then became to change the time zone on the device I'm using for the Authenticator to match the VSA's timezone. This worked and I was now able to reliably log in using the codes generated by the Authenticator.
Obviously this can't be a permament solution and this issue is now being further investigated. So hopefully the 31st of December deadline is not going to be enforced as this would seem to be a significant flaw in the system that might take some time to properly resolve.
Epic_Pete - Kaseya should have fixes to 2FA problems in a patch, without needing support. You can't accept having 2FA issues after patching and get locked out from VSA access. That threatens your ability to help your internal or external 'customers' and that should never be at stake.
My guess is the deadline will be part of patch .25 or .26, with the understanding it will be mandatory in the next patch. To me that would be an acceptable solution as you would have a month or two to configure and test. For such a big change that would be have to be crystal clear. That would also mean you could avoid this by not patching. That does mean you will be missing other fixes, until you're ready to fix and comply....