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

▲
8
▼

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.
active-directory
windows-server-2012
kerberos
windows
asked on Server Fault Mar 7, 2014 by rwwilden • edited Dec 20, 2017 by Rob

7 Answers

▲
7
▼

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.

answered on Server Fault Mar 7, 2014 by rwwilden • edited Oct 8, 2015 by rwwilden
▲
3
▼

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

answered on Server Fault Mar 7, 2014 by Simon L
▲
3
▼

Had same error and tried many different solutions. The one that helped was to use explicit IPv4 address instead of domain name.

answered on Server Fault Oct 8, 2015 by Sergey Mudrov
▲
3
▼

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!

answered on Server Fault Dec 29, 2016 by K3nnyg
▲
1
▼

This can happen when there are duplicate ServicePrincipalNames, which is a valid scenario but unfortunately confuses WinRM.

For example consider a service account 'appPoolAccount' and server 'myWebServer', both objects in Active Directory will have a ServicePrincipalName property containing the same string 'HTTP/myWebServer'. The ServicePrincipalName on myWebServer will be slightly different because it will be 'HTTP/myWebServer:5985

The presence of (near)duplicate ServicePrincipalNames will cause WinRM to fail with the Kerberos error in the question.

To workaround the issue, you can tell Invoke-Command to include the port when it searches for the ServicePrincipalName, like this:

### Tell WinRM to include the port in the SPN
Invoke-Command -ComputerName myWebServer -ScriptBlock {Get-Process} -SessionOption (New-PSSessionOption -IncludePortInSPN)
answered on Server Fault Jul 26, 2019 by Craig - MSFT
▲
1
▼

In my case, I had an HTTP/ SPN registered to an object that was owned by NOT the server. However, I couldn't find what owned it because the SETSPN.exe tool doesn't show you what container (or object) owns the SPN. I used the following PowerShell script to find the SPN's owner. After I deleted the SPN and recreated it with the server as the owner (using the SETSPN.exe tool), I waited 30 minutes for all the DCs to synchronize and then it worked.

# Source / credit:
# https://social.technet.microsoft.com/wiki/contents/articles/18996.active-directory-powershell-script-to-list-all-spns-used.aspx

Clear-Host
$Search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.Filter="(servicePrincipalName=*)"

## You can use this to filter for OU's:
## $Results = $Search.FindAll() | ?{ $_.Path -like '*OU=whatever,DC=whatever,DC=whatever*' }
$Results=$Search.FindAll()

foreach($Result in $Results ) {
  $UserEntry=$Result.GetDirectoryEntry()
  Write-Host "Object Name = " $UserEntry.name -BackgroundColor "yellow" -ForegroundColor "black"
  Write-Host "DN      =      "  $UserEntry.distinguishedName
  Write-Host "Object Cat. = "  $UserEntry.objectCategory
  Write-Host "servicePrincipalNames"

  $i=1
  foreach($SPN in $UserEntry.servicePrincipalName ) {
    Write-host "SPN(" $i ")   =      " $SPN
    $i++
  }

  Write-Host ""
}
answered on Server Fault Feb 13, 2020 by Slogmeister Extraordinaire
▲
-2
▼

I had an issue as well with Kerberos. It turned out to be a broken trust relationship between domain and server. Once I corrected this with PowerShell everything was fine again.

answered on Server Fault Dec 20, 2017 by Simon Blok

User contributions licensed under CC BY-SA 3.0