[V13] veeamadmin MFA setup

[leemurphy]

Hi,

I was wondering for the Software Appliance if there was a potential to move the MFA setting for the veeamadmin user from the initial set up to the first login. I understand the desire to mandate it but it would make just as much sense to require a user to set it up via the Web UI on the First Login after the webui is online and doing it in the console is kind of clunky in my opinion

[Dima P.]

Hello Lee,

We want to ensure that MFA for the host admin is enabled before we turn on web services and open the necessary ports, as this significantly reduces security risks. Thank you for your feedback!

[Gostev]

@Dima P. there's nothing to protect on a net new install though? So I think it's a good idea to move MFA configuration to the first login.
Remember that the initial Veeam Infrastructure Appliance connection is completely passwordless for the same reason: it's empty.

[CarlosEsteves]

I agree with suggestion: To make it to work in the installation from Web console in the VMware was very bad

[Dima P.]

We will discuss the possibility of moving MFA initialization into the web UI. Thank you for sharing your thoughts!

[DaStivi]

would add another vote for this!
I believe there is currently a bug in the MFA setup process.

I've tested it several times and noticed a few issues. First, the the font used to display the secret key for manual OTP setup is very hard to read. Characters like 1 and l, or O and 0, are nearly indistinguishable, which makes it easy to enter the wrong key. After several retries, I found that canceling and restarting the setup eventually displays a version of the key with more readable characters — but this workaround is far from ideal.

Even when I manage to enter the code correctly (I'm quite sure I did, despite the font issues), there's another problem: when I scan the QR code instead of entering the key manually, the generated OTP is different. I repeated this test multiple times. When entering the key manually in different tools, I consistently get the same OTP, and it works. However, scanning the QR code seems to generate a different secret, even though the setup dialog doesn’t show a new one.

Additionally, if I cancel the MFA setup and reopen it (without confirming the code), the secret key appears to be regenerated. I assume this is expected behavior and generally fine. However, the same issue persists: the QR code and the manually entered key still produce different OTPs..

maybe someone else Could please check if the secret used for the QR code is being regenerated or mismatched during the setup process?
not sure if i can or should open a support case on this? there aren't any logs of this... edit: i've create a case too now: Case #07827104

[HannesK]

when I scan the QR code instead of entering the key manually, the generated OTP is different

there is a known bug (1081697) in that area that should be fixed with 13.0.1

[Gostev]

@HannesK I thought I saw in the report that the QR code always works but there are some occasional issues with the key for manual entry. Are you saying it's the other way around? I guess this is a good candidate to document as the first known issue, although based on the number of active installs very few users seem to be running into it.

[HannesK]

yes, that's also my understanding. The QR code always works.

And if I need to guess, than Stephan is using a password manager and there he inserts the key manually and then there is a difference between an app that uses the QR code vs. the password manager

[DaStivi]

For my understanding, the OTP generated should always be the same as long as the same secret key is used—and that’s exactly what happens. The QR code is simply a visual representation of the secret key.

However, I suspect that when you click “Show QR Code” during setup, a new secret key is generated. Why do I think that? As long as I manually enter the original secret key and use the OTPs generated from it, the setup accepts them.

But once I click “Show QR Code,” only the OTPs generated from the QR code are accepted—the manually entered ones from the original secret key no longer work.

@HannesK I thought I saw in the report that the QR code always works but there are some occasional issues with the key for manual entry. Are you saying it's the other way around? I guess this is a good candidate to document as the first known issue, although based on the number of active installs very few users seem to be running into it.

This might cause problems when a user tries to generate OTPs using the secret key (for example, one stored in KeePass), and the codes don’t work—because someone scanned also the QR code during setup, which generated a different OTPs.

Imagine the authenticator app used to scan the QR code is lost or reset. The user then needs to recover access, because the OTPs are no longer valid. This mismatch can easily lead to confusion and potentially result in a support case.

[HannesK]

your understanding is correct and the bug will be fixed

[Gostev]

Super, thank you @DaStivi for laying the issue out so clearly. This goes directly into the Top Issues posts I'm about to publish.

[DaStivi]

i might have found another MFA Issue.

i just noticed that with the MFA enabled Veeamadmin user, i didn't get MFA using the Console... not sure if this is by design allready... but then i enabled MFA through the console and got another QR/Secretkey, resulting in another OTP .... now i've saved two users with different OTP...

i noticed now if i get back to the webinterface, the OTP from the inital Setup isn't working anymore... so the MFA from the Console also replaced it for the webUI and Host Management now!? initially i would assume that having MFA in the WebUI would also enable it for the console!

edit: i just noticed i even have 3 OTPs now... for the host managened console it looks like i've a nother OTP saved.. can't remember how i got this one...

[Gostev]

Different TOTPs are currently required for host management console and backup console access... there's already an existing thread about this requirement of two MFA codes elsewhere.

[DaStivi]

ok, then this is at least by design..

but having the MFA setup in console still overwrites the webUI console then... could also result in issues
as explained above, i would even expect that vbr (windows) console is automatically MFA enabled, when WebUI is MFA enabled and this is from the beginning.

[Gostev]

You are right. But they are currently two completely disconnected features: MFA for backup console has existed in the product for a while, while Host Management UI is a brand new feature exclusive to the software appliance deployment option (does not apply to V13 installable software for Windows at all). Therefore connecting the two dots is not very straightforward for the devs.