VBR 13 - Can't Add Group With Add-VBRUserRoleAssignment

Hi ​@NeonFrog,

Can’t give you experience here tbh, but since we are not a technical support instrument, I would recommend opening a support ticket for this. In case you encounter bugs there, they can be forwarded to our R&D / PM after the ticket process.

In case you do, please keep us posted. Interested in seeing the outcome!

Best

Lukas

Hi ​@NeonFrog - Welcome to the Community!

Did you look at the Veeam PoSH Reference for guidance?

https://helpcenter.veeam.com/docs/vbr/powershell/add-vbruserroleassignment.html?ver=13

Looks like an item to note is if Four-Eyes is enabled, this cmd cannot be run. Review the above and see if anything applies to your situation. Otherwise, as Lukas shared, Support is your next step.

Best.

Further to Shane’s information about 4-eyes, also ensure the user running the PowerShell commands does not have MFA enabled as well.  That causes problems, and you need to have a “service” account within the Console to disable MFA.

Thanks you for the suggestions! 

We double checked. The instances don’t have four eyes and the accounts running the commands do not have MFA enabled. We also compared the documentation for 13 against the working 12 and everything seems identical. (https://helpcenter.veeam.com/archive/backup/120/powershell/add-vbruserroleassignment.html)

We’ll open a support ticket and keep this thread updated.

Yes, we’ve run into this as well, and it does appear to be a v13‑specific PowerShell issue rather than anything you’re doing wrong.

We see the same behaviour you’re describing in 13.0.x (including 13.0.1.2067):

• Add-VBRUserRoleAssignment works fine for local users and domain users
• The same cmdlet fails for both local and AD groups
• Those exact same groups can be added without issue via the VBR console
• The same automation works perfectly on v12

So far, every v13 build we’ve tested behaves the same way.

From what we can tell, this looks like a regression in the v13 PowerShell layer, likely related to how group principals are being resolved internally. The backend clearly supports it (since the UI works), but the PowerShell cmdlet doesn’t appear to handle groups correctly anymore.

We weren’t able to work around it by:

• Changing name formats (DOMAIN\Group vs SID vs UPN)
• Using local vs domain groups
• Running PowerShell under different credentials

At this point we’ve parked group assignment automation for v13 and either:

• Pre‑seed groups manually via the console, or
• Limit automation to users only until this is fixed

If you haven’t already, I’d strongly recommend opening a support case with Veeam so it gets logged against v13 properly. This feels like something that should be addressed in a patch or 13.1, as it’s a clear parity break from v12.

If anyone’s found a REST API or other workaround, I’d be very interested to hear it—but as of now, this definitely looks like a product bug rather than configuration error.

How NTLM is used in Veeam (and why it still shows up)

At a high level, Veeam prefers Kerberos wherever possible, but NTLM is still used as a fallback depending on how the environment is built and how Windows is configured.

In domain‑based environments, Veeam follows normal Windows authentication rules:
if Kerberos is available and all prerequisites are met, Kerberos is used first; if not, Windows will silently fall back to NTLM, and Veeam goes along with that behaviour rather than forcing a protocol one way or the other 12.

This is why you’ll often still see NTLM references in logs even on modern versions.

Veeam v12 and later: Kerberos‑first, NTLM optional

Starting with Veeam Backup & Replication v12, it became possible to run in a Kerberos‑only configuration, with NTLM entirely disabled, as long as a few conditions are met 34:

• All Veeam infrastructure components are:
  • Domain‑joined
  • Added using FQDN, not IP or short names
• Time skew is within Kerberos tolerances
• No local (non‑domain) accounts are involved
• SMB repositories use Kerberos‑capable configs (e.g. domain auth, not local users)

If any of those conditions aren’t met, Windows authentication will fall back to NTLM, and Veeam will still function normally.

This is why:

• Disabling NTLMv1 is generally safe
• Disabling NTLM entirely requires validation and testing
• Veeam logs may still mention NTLM even in Kerberos‑capable environments 54

What changes in Veeam v13

Veeam 13 introduces an important split depending on platform:

✅ Windows‑based VBR servers

• NTLM is still supported
• Kerberos is preferred if available
• Actual protocol choice depends on Windows security policy
• Veeam does not override OS authentication behaviour 2

So if NTLM is enabled on the OS, Veeam may still use it in some scenarios.

🚫 Veeam Software Appliance (Linux‑based)

• NTLM is not available at all
• Runs in FIPS‑compliant / DISA STIG‑hardened mode
• Kerberos, certificate auth, or token‑based mechanisms must be used instead
• This can surface auth issues that were previously masked by NTLM fallback 2

This distinction is critical when comparing behaviour between appliance and Windows deployments.

Why NTLM still matters in real environments

Despite best‑practice guidance, NTLM is still commonly required in scenarios such as:

• Workgroup or non‑domain VBR servers
• SMB repositories using local users
• Legacy NAS devices or storage firmware
• IP‑based connections instead of FQDN
• Certain PowerShell or automation paths

Veeam explicitly supports NTLM for backward compatibility, but strongly encourages customers to phase it out over time 3.

NTLM and security posture

Veeam’s own guidance is:

• ✅ Disable LM and NTLMv1
• ✅ Allow only NTLMv2 if NTLM is required
• ✅ Audit NTLM usage before disabling completely
• ✅ Move toward Kerberos‑only where feasible

This aligns with broader Microsoft guidance and Veeam’s Security & Compliance Analyzer checks 67.

Practical takeaway

In short:

• NTLM showing up in Veeam logs does not automatically mean misconfiguration
• Veeam uses whatever auth protocol Windows provides
• v12+ supports Kerberos‑only, but only if the environment is clean enough
• v13 appliance cannot fall back to NTLM at all
• Many “new” v13 issues are actually NTLM fallbacks disappearing

If you're running mixed environments or heavy automation, NTLM removal tends to expose assumptions that previously went unnoticed.

Yeah...about the best you can do at this point (open a case). If it’s a bug...Support should be able to get you a fix “soon”, and hopefully an update can be rolled out at some point to fix this wholistically. Keep us posted.

Are you running the PowerShell commands in PS 5.1 or PS 7?  You need PS 7 now with Veeam 13.  Just FYI.

Can you show exact command you used? (with all parameters present and filled in, you can anonymize the parameter values, just need to see what you fed -Name)

v13 adds a few new concepts to users / roles as we added Identity Service, so it’s possible that this cmdlet needs to be updated.

As a sanity check, can you add the group manually in the Remote Console, then fetch it with Get-VBRUserRoleAssignment? How does the name show there? If you use that format does it work?