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 126.96.36.199.
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....
Luckily you can disable the whole thing.
For us this is the best solution since it removes the scary alert and does not asks users to try enrolling, fail
and lock themselves out.
For us what worked is:
set Data = 'https://server'
where Setting = 'SASURL';
And then you can remove all enrollment from all users using the Logon Policy menu.
Once that's done you are good to go, you don't have 2FA but the system works.
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.