[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.