Has anybody had any luck using an alternative vendor (such as the Azure MFA) to gain access to the Kaseya VSA?
My current organisation relies on the MFA token elsewhere and we'd like to use it for the VSA but it seems that it doesn't want to play ball.
I've used AuthAnvil previously and it certainly does what it is supposed to but the new pricing structure is out of reach for us as we only need MFA for a half dozen or so engineers. We don't need, nor do we want to pay for access to, the full-blown add-in interface with windows client authentication for logging onto the OS etc.
I'm sorry that you feel like our new pricing model is out of reach for you. I'll certainly bring your point up with the leadership team. And, while I can't comment on third-party solutions, if there's anything else on your mind that's AuthAnvil-related, I'd be happy to listen.
As fas as I know Kaseya really doesnt support any standard external authentication methods so there is little luck to get any 3rd party MFA work.
The reality is that Kaseya charging for 2FA and requiring the use of Auth Anvil is ridiculous without regard to the cost. A good example of how they should do 2FA is the model provided by Screen Connect. You can choose your 2FA method email. Google, etc and it is built into the program. It is a feature that should be built into Kaseya as well and should not cost additional dollars to gain access to it. Very disappointed in Kaseya trying to charge more for security that should be included.
I don't really care that they have and want to promote their own product, but it seems like they've deliberately put 0 effort into making their product compatible with other 2FA products out there. Frankly, my company IT team would probably rather I drop Kaseya entirely and switch to a RMM that will support their 2FA they've rolled out company-wide than adopt another 2FA product on top of the one they already have.
And worse still, every time I've tried to get a quote for the AuthAnvil they want to stick me on a 3 year contract up front and then my IT department gets sticker-shock instead of just doing YoY. It's like they're just deliberately doing everything they possibly can to get people to avoid buying this product.
This hardball they're playing over 2FA ends up meaning my customer sites are less secure and I am getting pressured internally to just drop the VSA product altogether. Not sure if Kaseya ever listens to this, but this game they're playing over 2FA is absolutely not worth the trouble.
And it's sad people are digging up 3 year old threads because this is still a problem and people called it out ages ago.
That is true. I got a quote for AuthAnvil from kaseya and it is way expensive if want to use it for 10 users. With extreme pressure from my team we have started laying off add-on like KAV, KES, BUDR etc and rather switch to vendors directly which is way less expensive. Though there is an addition console we need to manage but that is what we system admins are here for. Wish Kaseya listen to all above remarks and try to bring down there price.
I'm in the same boat at Rajeev, we only have 10 users but we want our VSA secured. Please could you make Auth Anvil price effective for companies our size who want to protect their VSA from all the security hacks around at the moment????
I am using AuthAnvil to secure access to VSA for Admins and am pretty much ignoring all the other options that come with it.
Shame there does not appear to be any integration options with the likes of MS Authenticator.
or MS Azure.
The obvious situation here is all of the MSPs using Kaseya are sitting ducks until one of us gets compromised much like the scenario with Teamviewer* a few years back when they refused to add an extra layer of security for their logins (of which the majority use is on the MSP side) until it was too late. Kaseya should really consider the negligence on their part of not making the proper investments in securing their customers' logins. They would be wise to look to their peers in the industry, notably Teamviewer and Apple iCloud**, and not wait for the next big incident.
Just as a heads up, I am currently using Kaseya VSA integrated with our AzureAD tenant which includes MFA. There are a couple of tricks to it, basically you have to put in some dummy data into VSA to make it think it has AuthAnvil. The same applies to BMS as well, that ultimately you have to tell it you have AuthAnvil so that it breaks authentication directly, and you must always auth to AzureAD first then you can pass through to VSA/BMS. But once you add the shortcuts to your 365 tenant, it just works. I login to my Office 365 portal, go through my 2FA/MFA check, click VSA or BMS and am passed through. If I use try accessing either BMS or VSA directly it will refuse to log me in.
So it is possible to do, and in theory should be compatible with just about any 3rd party authentication system using SAML. BUT the problem is that their support, and their documentation are heavily geared towards AuthAnvil. Which is a shame, because there are so many people out there using Office 365 or other SAML style platforms, why not document it clearly about what settings you accept? I had tickets open with their support team and they would constantly point me back to Microsoft, oh it's a Microsoft problem go talk to them. No it's a Kaseya issue, because your documentation is incomplete. I've heard rumors that there was once upon a time better documentation, but it has been removed because of AuthAnvil and the push to sell that. But who knows.
Ultimately, it's possible to do, at some point I was thinking about putting together a blog post on how to exactly get it working but just haven't had the time. If there is interest I could knock something out from my personal blog.
We're currently in the middle of a project rolling out an OKTA integration for SSO and MFA to all of our primary internal applications including Kaseya. Options are there.
I would be very keen to learn how you did this being a AzureAD tenant as well.
I am only using AuthAnvil to protect VSA logins so a blog post would be brilliant!
Could you elaborate on this? "There are a couple of tricks to it, basically you have to put in some dummy data into VSA to make it think it has AuthAnvil."
It doesn't appear you need to do anything more on the Kaseya side than upload the correct certificate and check "Enable Single Sign On to Kaseya". If you're stuck with your particular IdP it can be helpful to try Okta first and then examine the SAML using a browser to see what format Kaseya expects it in. Okta is officially supported and Kaseya has a KB on how to set it up. They also offer a 30 day trial. It was really easy set up in Okta.
The dummy data is mainly so that Kaseya VSA will accept that there is AuthAnvil and disable user login directly. Otherwise technically users can still hit the normal login page and bypass your external auth service, which for our setup would mean bypassing MFA
In your AuthAnvil -> Two Factor Auth -> Configure Kaseya Login, set your AuthAnvil SAS URL to demo.my.authanvil.com/.../sas.asmx, set your site ID to a random number, and then ideally whitelist at least one user just in case. Set your config to require two factor auth for all users except those whitelisted which should prevent direct user logons for everything except your backup account, which make sure has a very good password and is not used for anything else.
Outside of that, you need to upload your certificate you got from AzureAD and enable SSO as per normal and set your reply to URL to the following xxxxxxxx.kaseya.net/.../ssologin.aspx replacing the xxxx with your tenant.
On the AzureAD side, you create an Enterprise Application. In your Basic SAML configuration both the identifier (Identity ID) and Reply URL (Assertion Consumer Service URL) will be
xxxxxxxx.kaseya.net/.../ssologin.aspx with your tenant replaced in there.
Your user attributes and claims will vary depending on what you use as your identifier, you need some identifier that will match the username you are using in VSA. For us it is simply the unique user identifier is user.userprincipalname.
For your SAML Signing Certificate you need to set your signing option to Sign SAML Response, and your Signing Algorithm to SHA-1.
And after you have this setup you can download your cert and load it into VSA.
That's really it, this should prevent direct user login as VSA thinks AuthAnvil is functional when it's not going to work. The demo URL allows the form to accept the URL as if you enter in something broken it checks and fails to save. And ideally you'd get users to use the AzureAD URL which does SSO, or add it to your main portal page.