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

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!

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.

Yeah, I’m quite aware ;) 

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

Same issue. None of this helps.

​@Alan.Forrest, best to open a Support Case and let Veeam Support review -- last cases required review of the debug logs to understand the issue, so please open a Support Case and let support begin the investigation.

Same issue here upgrading from v.12 to v.13.  UPN is set correctly for the account used to install and the one with the failing login attempts.  This should not be an issue.

Was seeing similar issue after upgrade from 12.3.2.3617 to 13.0.2.29

UPN was not set on the account used to do the upgrade, added the UPN and resolve it.

Have you solved your problem? Please share your solution.

Have you solved your problem? Please share your solution.

.

new case #08040224 opened since old case#07982705  was achieved

If that is the case, then keep up with the support case to get it resolved.  The UPN fixed it for our users but maybe your case is something slightly different.

Curious to hear what Support comes up with for you ​@RandomUser . Keep us posted if you could.

Best.

​@Tommy O'Shea ​@Chris.Childerhose - we are also facing exactly same issue after V13 upgrade, unable to login to with our admin account ‘Failed to retrieve user information’. Case #07982705 already opened but no luck.

In our case, userPrincipalName is already set correct and allowed user in VBR user & roles but still same issue. 

Just a heads-up: in our case, the issue was caused by a special character ($) in the username of a local user account.

Thanks for sharing ​@Tommy O'Shea 

Ok...well Veeam using the UPN for AD accounts makes sense. Thanks for sharing the resolution Tommy. Glad they got it resolved for you all.

Thanks David.  Seems it was not required in v12 but is in v13.

Ah, funny :) Support had asked me about this very thing, I didn’t realize they were talking about your case.

Yes, Veeam has a check right now to retrieve the userPrincipalName property from AD -- I’m not an AD / Kerberos expert, but seems we expect it to be there. 

I’ll bring it up internally and confirm it’s required, and we’ll add it to the User Guide.

I am guessing the UPN is needed in v13 for some reason.  I already have a PowerShell script to fix any other users we find too.  😋

I’d rather not recreate the user at this stage, since it seems more like it’s authenticating fine, just Veeam can’t find the association between the AD account and the Veeam database. I don’t want this cropping up later and affecting other users. Like Chris said, hopefully Veeam support comes back with a fix for the identity error.

I was just wondering if anyone else had seen this specific error message already.

There are no special characters in the usernames we use.  I am the one that set up the new domain for our Veeam servers and worked on all this so it should be good. 😁

We will wait on the current support case to see what is going on.

This is not necessary because my account and others work on the Veeam server (I work with Tommy).  So it is not a domain join issue.

Hmm..weird behavior there. Curious what Support finds Tommy.