Couldn't find this documented anywhere, but changing the Veeam BR services account back to Local System, found an issue where none of the VBR consoles were able to login any more. The issue is stale SPN records in AD
This is logged in Event Log (Security-Kerberos Event ID 4):
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server hyperv$. The target name used was VeeamBackupSvc/hyperv.example.com.
This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered
on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can
also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service.
Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target
domain (EXAMPLE.COM) is different from the client domain (EXAMPLE.COM), check if there are identically named server accounts in these two domains,
or use the fully-qualified name to identify the server.
After deleting all of those with setspn -D <spn> <VBRSvcAccount>, everything works again. Here's the relevant MS troubleshooting documentation: Kerberos Service Principal Name on Wrong Account
Search engines should index the forums, so your post should be found over time. Which version are you using? I only remember https://www.veeam.com/kb4393 which applies to Kerberos-only environments. Are you using "kerberos only"?
Depending on how many customers come up with your scenario to support, we might create a KB article. But right now, the situation is unclear when this really happens. I mean, all Veeam Backup & Replication services should always run as "local system". Documenting things that are "unintentionally broken by customer" is also a bit "complicated" for us
That KB is the opposite situation - it says to create those SPNs, the issue here was that the (outdated) SPNs are not wanted. No worries, this is just a messy testing playground setup.