Solved

Error when logging into console after upgrade: "Failed to retrieve user account information"

Forum|Forum|7 months ago
January 20, 2026
28 comments
3447 views

+5

Tommy O'Shea
Veeam Legend

I’m getting the below error after upgrading Veeam servers from v12 to the latest release of v13. It’s a windows based install of Veeam, and it is connected to a (dedicated to Veeam only) AD domain.

My user has local administrator permissions, Veeam Backup Administrator permissions, and MFA disabled for testing/troubleshooting purposes. The is happening across each of the Veeam v13 servers I have on the domain.

It is only happening for mine and one other engineer’s user accounts, but other engineer’s accounts are not affected. We are all in the same AD groups so permissions are the same.

I have tried removing Veeam Backup Administrator permissions from my account, rebooting, and re-adding, to no effect.

Has anyone seen this before? Any suggestions for what else to check? In the meantime I have a case open with Veeam support, and hoping they can come up with something.

Relevant logs:

[19.01.2026 21:07:36.194] <126> Error (1) Veeam.Backup.IdentityService.Shared.CSystemAccountProvider [TraceId: '400000e0-0024-fb00-b63f-84710c7967bb'] Unable to get user S-1-5-21-████-████-████ (SID redacted)
identity from account

[19.01.2026 21:07:36.194] <126> Error (1) Veeam.Backup.Identity.Server.GssEndpoint [TraceId: '400000e0-0024-fb00-b63f-84710c7967bb'] Could not get identity after success authentication for
'DOMAIN\Username'

Best answer by Tommy O'Shea

Veeam support just got back to me asking if my account’s userPrincipalName attribute was set in AD or was empty. @Chris.Childerhose checked for me, and it was indeed <not set>.

Once we corrected that, I was able to log into the Veeam server again.

What’s interesting is that I had no problem logging into v12 server like this, only v13. Perhaps v13 has a requirement for that attribute to be set.

Show first post

1
2

Forum|pagination.label 2 / 2

D

+3

ddomask
Veeam Product Management
Forum|Forum|3 days ago
August 20, 2026

Hi @clmr_bry, then a Support Case is the way to go as a review of the debug logs will be required.

0x0D 0x0A

Like

C

clmr_bry
New Here
Forum|Forum|3 days ago
August 20, 2026

Hi @clmr_bry, then a Support Case is the way to go as a review of the debug logs will be required.

Yeah, I’m quite aware ;)

Like

C

clmr_bry
New Here
Forum|Forum|2 days ago
August 21, 2026

FWIW:

I’m seeing what appears to be a related VBR 13 identity-resolution issue, but my userPrincipalName is populated so the resolution above doesn’t apply here. The Identity Service successfully authenticates me, finds my account by SID, and then fails with:

Failed to get 'userAccountControl' property from search result

Direct LDAP queries return userAccountControl=66048, but the same query under SYSTEM finds the account without returning that attribute, apparently because the account is in a restricted OU. But this worked in VBR 12. It looks like VBR 13’s new Identity Service assumes certain AD attributes are both populated and readable, then aborts login with the generic “Failed to retrieve user account information” error when one is missing.

As a temporary workaround, I run VeeamBackupSvc under a dedicated domain service account and explicitly log into Veeam using that account. With embedded PostgreSQL, I also had to add that identity to the veeam map in pg_ident.conf.

This does not fix normal login for the original domain users; it only provides a workable administrative login until the AD permissions or Veeam behavior are corrected.

Like

1
2

Forum|pagination.label 2 / 2

Sign up

Login to the community