Windows – Add new server to Server Manager, get Kerberos error 0x80090322

active-directorykerberoswindowswindows-server-2012

I'm setting up a Windows lab environment. It has a Win2012R2 domain controller (srv001) and I'd like to add another Win2012R2 server to the domain (srv003). Actually, all goes well. I gave the new server a static IP address in the same subnet as the DC, pointed it to the right DNS server and added the server to the domain.

However, when I add the new server to Server Manager, I get a Kerberos error: 0x80090322. I has quite a long error message that I'll post below. I did some testing and found out that I'm actually able to setup a remote Powershell session to the server using Kerberos authentication:

$s = New-PSSession -ComputerName srv003 -Authentication Kerberos
$s | Enter-PSSession

No problems here. I ran Enable-PSRemoting on the remote server, no problems there as well.

Why doesn't Server Manager like my new server? Especially since it's possible to set up a remote Powershell using the same protocol Server Manager is complaining about.

The error message that belongs to error code 0x80090322:

Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. Possible causes are:

  1. The user name or password specified are invalid.
  2. Kerberos is used when no authentication method and no user name are specified.
  3. Kerberos accepts domain user names, but not local user names.
  4. The Service Principal Name (SPN) for the remote computer name and port does not exist.
  5. The client and remote computers are in different domains and there is no trust between the two domains.

After checking for the above issues, try the following:

  1. Check the Event Viewer for events related to authentication.
  2. Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated.
  3. For more information about WinRM configuration, run the following command: winrm help config.

To refer back to the numbered items in the error message:

  1. I use a domain admin account to do this.
  2. Not sure how to change this in Server Manager so I suppose the default should do it.
  3. I'm running inside the domain, starting Server Manager as a domain admin.
  4. The server actually has the following SPN's which I haven't touched:
    1. Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/srv003.rwwilden01.local
    2. TERMSRV/SRV003
    3. TERMSRV/srv003.rwwilden01.local
    4. WSMAN/srv003
    5. WSMAN/srv003.rwwilden01.local
    6. RestrictedKrbHost/SRV003
    7. HOST/SRV003
    8. RestrictedKrbHost/srv003.rwwilden01.local
    9. HOST/srv003.rwwilden01.local
  5. Both computers are in the same domain.
  6. No events on the client machine.
  7. It shouldn't be necessary to do this.

Best Answer

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.

Related Topic