Add new server to Server Manager, get Kerberos error 0x80090322
Solution 1:
Ok, I finally figured it out. I took another good look at the event log of the remote server. It contained an error with the following error text:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server srv003. The target name used was HTTP/srv003.rwwilden01.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (RWWILDEN01.LOCAL) is different from the client domain (RWWILDEN01.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
It appeared I had added a managed service account a week earlier with SPN HTTP/srv003.rwwilden.local. I'm not sure why Server Manager attempts this target name first but apparently this doesn't work. Makes sense since this SPN has little to do with the actual server.
After I removed the service account, everything started working as I intended.
Solution 2:
I had this problem not long ago, I got pointed towards the culprit by using the "setspn" tool. I got a better understanding of SPNs by reading this article : http://support.microsoft.com/default.aspx?scid=kb;EN-US;929650
Solution 3:
Had same error and tried many different solutions. The one that helped was to use explicit IPv4 address instead of domain name.
Solution 4:
I couldn't add a comment (New job, new account, no points)to the post I wanted to so I'm replying. The reason why using an IP helps/solves the problem is because when an IP is used Kerberos is not used. Kerb is only attempted when a FQDN is used (or a NBT name but that's only because it appends the domain name making it fqdn anyways). Generally speaking most Kerberos errors are because of either naming OR the SPN not being set or set correctly for the service you require. Cnames don't work btw unless you turn off strict name checking and even then will not work under some circumstances so I suggest you stay away from them at least while diagnosing. But honestly...the BEST approach to figure this kind of stuff out (because Windows logs and Kerb aren't that helpful) is to use Wireshark. you will see the negotiation and you will see why it fails, what its trying, etc. Additionally if you enable "analytic and debug" logs in Event viewer you will get additional debug logs for Kerb that you can enable that are a bit more helpful. Still...Wireshark is always your friend imho!