Skip to main content
Solved

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

  • January 20, 2026
  • 29 comments
  • 3901 views

Show first post

29 comments

Forum|alt.badge.img+3
  • Veeam Product Management
  • 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.


  • New Here
  • 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 ;) 


  • New Here
  • 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.


  • New Here
  • October 2, 2026

Just FYI —Rejoining domain, PrincipalName, etc. did not work for me.

However, when I checked the Svc.Identity.log, I noticed the following error:

“Could not get identity after success authentication for 'DOMAIN\Admin'”

It was showing DOMAIN\UserName instead of DOMAIN.COM\UserName.

On the Domain Controller, I checked AD Users and Groups → right-click DOMAIN.COM → Properties, and noticed that the Domain Name is actually set to “DOMAIN”, not “DOMAIN.com.”

I then edited the following file:

C:\Windows\System32\drivers\etc\hosts

and added the Domain Controller’s IP address with the hostname DOMAIN.

That resolved the issue for me.

Thanks to Juan from Tech Support for the help!