Skip to main content
  • EN

I was today the first day in the office after my vacation. After starting my VBR V12 BETA3 instance, I noticed that the trial license has expired at 12/31/2022.

At login I was stunned that the second factor for login was not active.

So, I had a look at the “Users and Roles” dialog and there was no checkbox “Require two-factor authentication for interactive logon” available.

“Users and Roles” Dialog without “Require two-factor authentication for interactive logon” available

OK, the difference to my last login before Christmas is the expired license. I installed our NFR license and checked the “Users and Roles” dialog again.

Now the checkbox “Require two-factor authentication for interactive logon” is available again and the 2FA is working again at next login.

“Users and Roles” Dialog with “Require two-factor authentication for interactive logon” available

Conclusion is that – at least with the BETA version – 2FA is available only with a valid license. Your installation is left without a more secure login method unintentionally.

So, be aware to keep your licenses up to date to avoid this situation - most users will be hopefully not get in this situation.

But all users with a community edition will have no 2FA protection at all….

thanks for showing it,

It make sense not being able to login with a expired license, but a message or box with info would be great to have!

cheers.

Oh, you are able to login. Just the 2FA is switched off….

Oh, you are able to login. Just the 2FA is switched off….

Good to know, thanks for sharing!

I had raised this as a question on how it should be handled, but the end result is that this is intended behavior.

Good to know this but I installed a license from work for v11 which works and has kept this enabled for me.  Great post though. 👍

Yes, hopefully not many users will run into this as most licenses are renewed automatically… I was just surprised today morning 😎

But all users of a community edition will not have 2FA protection at all.

I had raised this as a question on how it should be handled, but the end result is that this is intended behavior.

@Rick Vanover Do you know what's the reason for that? Is 2FA not part of the community edition? Just wondering if an attacker could remove the license from the backupserver and disable 2FA with that. Although that doesn't matter much if he works with administrative permissions on the VBR server.

I had raised this as a question on how it should be handled, but the end result is that this is intended behavior.

 

Soo...in theory, could the date be changed on the server ahead enough days that the license expires and then MFA is effectively bypassed?  This seems like a bad idea if this is the case…

I don’t have the Beta installed (I was getting ready to but then it sounded like we may have the RTM in our hands soon so I held off).  I have concerns (noted above) that MFA could be bypassed by advancing the date on the server to where the license will have expired. 

Also, if this is intentional…Community Edition gets no MFA, then I’m a little bit upset.  I’ve been known to complain about Microsoft making Conditional Access Policies a premium product behind the Azure AD Premium P1 or P2 licensing on M365.  I know that it’s a nice to have and premium features cost money, but I feel that something like MFA really should be a default available at all levels and not a premium feature that is paywalled.  In the case of M365, Security Defaults is just okay, and per-use MFA activation is pretty terribly leaving gaps for users to be missed, etc.  CAP is really the only decent option.  I’ll be disappointed if Veeam took a similar stance on a security-related feature.

Yes, it should be possible to deactivate 2FA with a date change - I haven't tried it yet, though. But if an attacker is able to change the date on your backup server you have some more problems than 2FA….

I had raised this as a question on how it should be handled, but the end result is that this is intended behavior.

 

Soo...in theory, could the date be changed on the server ahead enough days that the license expires and then MFA is effectively bypassed?  This seems like a bad idea if this is the case…

This would be a bad idea but as said by others if someone can change the date you can forget about the MFA anyway. 😂

RE: the date change…

 

This is why I still recommend session (OS) MFA. This was the nature of the ask at the Veeam100 Summit. But let’s see how it goes. There is a mindset in the product team that “one shouldn’t have to pay extra for security” → Example the VHR (Veeam Hardened Repository) is included in the Community Edition. 

Yeah, we use Duo for admin logins to the OS, but non-admin generally isn’t required MFA for most of our clients.  And I agree…if they’re in the OS, you have other issues already, but I think you could have less access to do damage in the OS but with MFA required to the console than OS access with MFA bypassed.  I appreciate the though process of not paying extra for security…security is a selling point to using the software in and of itself.

Yeah, we use Duo for admin logins to the OS, but non-admin generally isn’t required MFA for most of our clients.  And I agree…if they’re in the OS, you have other issues already, but I think you could have less access to do damage in the OS but with MFA required to the console than OS access with MFA bypassed.  I appreciate the though process of not paying extra for security…security is a selling point to using the software in and of itself.

I made the argument for MFA on the console, if the attacker has access to the OS, then the worst they could do is wipe the VBR server, but your backups and config backups are still on your hardened repo, so while an inconvenience, it’s just a case of spinning up a new VBR server, restoring config and importing backups. Without MFA on the console, then it’s whole world of pain of deleted backups etc ... 

Yeah, we use Duo for admin logins to the OS, but non-admin generally isn’t required MFA for most of our clients.  And I agree…if they’re in the OS, you have other issues already, but I think you could have less access to do damage in the OS but with MFA required to the console than OS access with MFA bypassed.  I appreciate the though process of not paying extra for security…security is a selling point to using the software in and of itself.

I made the argument for MFA on the console, if the attacker has access to the OS, then the worst they could do is wipe the VBR server, but your backups and config backups are still on your hardened repo, so while an inconvenience, it’s just a case of spinning up a new VBR server, restoring config and importing backups. Without MFA on the console, then it’s whole world of pain of deleted backups etc ... 

Yeah, I would have to agree with that one Craig as a Pro for this.  Hopefully they take that in to account.

Yeah, we use Duo for admin logins to the OS, but non-admin generally isn’t required MFA for most of our clients.  And I agree…if they’re in the OS, you have other issues already, but I think you could have less access to do damage in the OS but with MFA required to the console than OS access with MFA bypassed.  I appreciate the though process of not paying extra for security…security is a selling point to using the software in and of itself.

I made the argument for MFA on the console, if the attacker has access to the OS, then the worst they could do is wipe the VBR server, but your backups and config backups are still on your hardened repo, so while an inconvenience, it’s just a case of spinning up a new VBR server, restoring config and importing backups. Without MFA on the console, then it’s whole world of pain of deleted backups etc ... 

Fair point - and that’s assuming a distributed deployment - I can’t always assume that however with broad stroke advice.

Yeah, we use Duo for admin logins to the OS, but non-admin generally isn’t required MFA for most of our clients.  And I agree…if they’re in the OS, you have other issues already, but I think you could have less access to do damage in the OS but with MFA required to the console than OS access with MFA bypassed.  I appreciate the though process of not paying extra for security…security is a selling point to using the software in and of itself.

I made the argument for MFA on the console, if the attacker has access to the OS, then the worst they could do is wipe the VBR server, but your backups and config backups are still on your hardened repo, so while an inconvenience, it’s just a case of spinning up a new VBR server, restoring config and importing backups. Without MFA on the console, then it’s whole world of pain of deleted backups etc ... 

Fair point - and that’s assuming a distributed deployment - I can’t always assume that however with broad stroke advice.

That’s why you have best practises 😉

Comment


Terms & Conditions