With ransomware and cybersecurity attacks in the news almost daily, disaster recovery applications are looking to features that take defense and protections very seriously. Often the easiest rung to reach in terms of good application security is having Multi-Factor Authentication (MFA) required for logins. For many people, MFA is old hat, but for those who are unfamiliar with it, modern MFA can take various forms. Here are some examples:
- SMS Authentication: includes codes that are pushed from the website to you via SMS text messages. This is better than not have any security at all, but it is also easily spoofable.
- OTP Apps: includes apps such as Google Authenticator, Authy or 1password that provide the codes based on scanning a QR code typically to setup then using your mobile device to generate the code
- Push MFA: apps such as Duo or Gmail that when you authenticate it triggers a push notification to a particular instance of a mobile app that is also authenticated
With Veeam Backup and Replication v12 upcoming release, Veeam is now supporting OTP App MFA in their console application. This takes a little bit of setup. In my particular experience, it is a little quirky, but it does definitely work. Let’s walk through how to put this in effect.
How to Enable MFA in VBR v12
- Once you have v12 Console installed, either the local or remote version, open it and navigate to Users and Roles.
- MFA in VBR is not supported with any use of groups. By default, members of the local Adminstrators group are given the Veeam Backup Administrator role. So we need to start by adding your own login first. You can do this with the Add button.
If you weren’t already aware, you should notice that there are number of roles that can be selected. More information about what each of these can do is available in the HelpCenter documentation.NOTE: One thing I’ll add here is that I noticed a quirk in some of our setups. If you use the browse method — and if for some reason the NetBIOS domain is not just the portion before the first dot in the FQDN domain (for example prem for prem.lab.internal) — then by default the User or group in the blank above is filled in incorrectly. In a few of our test environments, we are using the full FQDN without the dots as the NetBIOS name. This led to some issues that were easily fixed by just typing the correct domain in the blank. This feedback has been shared and I imagine it will be fixed before GA.If by chance you do NOT remove the groups before enabling MFA and then hit OK, you will receive an error message. Again, simply remove the groups to get past this error.
- It is important to understand that once you protect an account with MFA you will not be able to use it with automation methods such as PowerShell. To allow for this you will need to create an automation specific user, preferably with a very robust and often changed password, and set it in VBR as a service account to disable MFA. Complete adding your needed users and check the “Require two-factor authentication for interactive logon” to complete the server setup portion.
- Once you setup your accounts in Veeam Console, you will need to close out and relaunch to get into the MFA registration wizard. You would do this as you normally would, either using Windows session authentication or filling in the username and password.
- Once you hit Connect, you will get the standard MFA QR code for registration. Simply open the app of your choice and add by scanning the QR code, and then supply an active confirmation code to complete setup.
And with that you have now enabled two-factor authentication for your Veeam Backup and Replication users. You can potentially increase this further by not giving permissions to the user’s Windows logon account but instead doing a secondary, application-specific account, making them type in a username and password follow Step 4 above. In that scenario, you would have to authenticate to Windows, authenticate to Veeam and then provide an MFA code. That would all just depend on your organization’s security needs.
At the end of the day, security practices should be a part of everything we do as IT and Disaster Recovery administrators. Little things like requiring MFA for our critical backups add up to a well-designed, layered security model.
