So I did some more digging with Gemini and it seems that the Kerberos ticket for the user is based on the password so when you restore a user if this is out of sync with the Domain Controllers then resetting the password is the best course of action.  There are other options to reset the Kerberos Ticket for a user as noted below.

 

🔍 Why Kerberos Breaks After Restoring an AD User

When you restore an Active Directory user object from backup, Veeam brings back:

• The old password hash
• The old Kerberos keys (derived from the password)
• The old timestamps (like pwdLastSet, lastLogonTimestamp, etc.)

Kerberos relies heavily on cryptographic keys derived from the user’s password. If the restored object’s keys are out of sync with what the domain controllers expect, the user can authenticate via NTLM but Kerberos ticket creation fails.

This is exactly what the community report describes:

“The user could logon into computers, but he wouldn’t get any kerberos tickets. Only after a password change the behavior was completely normal.” Veeam Community Resource Hub

✅ Root Cause

Kerberos keys are generated from:

• The user’s password
• The salt (usually username + domain)
• Timestamps

When you restore an older version of the user object:

• The password hash is old
• The Kerberos encryption keys are old
• The Key Version Number (KVNO) may no longer match what the KDC expects

So the KDC refuses to issue a TGT.

Changing the password forces AD to:

• Generate new Kerberos keys
• Update KVNO
• Sync the object across domain controllers

…and Kerberos starts working again.

✅ How to Fix It

✅ 1. Change the user’s password

This immediately regenerates Kerberos keys and resolves the issue.

✅ 2. If you cannot change the password

You can force a key regeneration using:

Set-ADAccountPassword -Identity username -Reset

or

ksetup /setcomputerpassword

…but realistically, a password reset is the cleanest fix.

✅ How to Prevent This in the Future

If you frequently restore AD objects, consider:

✅ Use authoritative restore only when needed

Non-authoritative restores can cause replication mismatches.

✅ Avoid restoring very old AD user versions

The older the backup, the more likely Kerberos keys will be stale.

✅ Use Veeam’s AD Explorer carefully

It restores the object exactly as it was — including outdated Kerberos metadata.