Добавьте новый сервер в диспетчер серверов, получите ошибку Kerberos 0x80090322

Хорошо, наконец-то разобрался. Я еще раз внимательно просмотрел журнал событий удаленного сервера. Он содержал ошибку со следующим текстом ошибки:

Клиент Kerberos получил KRB_AP_ERR_MODIFIED ошибка с сервера srv003. Используемое целевое имя было HTTP / srv003.rwwilden01.local. Это указывает на то, что целевому серверу не удалось расшифровать билет, предоставленный клиентом. Это может произойти, если основное имя целевого сервера (SPN) зарегистрировано в учетной записи, отличной от учетной записи, которую использует целевая служба. Убедитесь, что целевое SPN зарегистрировано только в учетной записи, используемой сервером. Эта ошибка также может произойти, если пароль учетной записи целевой службы отличается от того, который настроен в Центре распространения ключей Kerberos для этой целевой службы. Убедитесь, что служба на сервере и KDC настроены на использование одного и того же пароля. Если имя сервера не полностью определено, а целевой домен (RWWILDEN01.LOCAL) отличается от клиентского домена (RWWILDEN01.LOCAL), проверьте, есть ли учетные записи сервера с одинаковыми именами в этих двух доменах, или используйте полное имя для идентификации сервера.

Оказалось, что неделей ранее я добавил управляемую учетную запись службы с SPN. HTTP/srv003.rwwilden.local. Я не уверен, почему диспетчер сервера сначала пытается использовать это целевое имя, но, видимо, это не работает. Имеет смысл, поскольку это SPN имеет мало общего с фактическим сервером.

После того как я удалил сервисный аккаунт, все заработало так, как я задумал.

У меня была эта проблема не так давно, меня указали на виновника с помощью инструмента "setspn". Я лучше понял SPN, прочитав эту статью: http://support.microsoft.com/default.aspx?scid=kb;EN-US;929650

Я не смог добавить комментарий (новая работа, новый аккаунт, без баллов) к записи, которую хотел, поэтому отвечаю. Причина, по которой использование IP-адреса помогает / решает проблему, заключается в том, что при использовании IP-адреса Kerberos не используется. Curb выполняется только тогда, когда используется полное доменное имя (или имя NBT, но только потому, что оно добавляет доменное имя, в любом случае делая его fqdn). Вообще говоря, большинство ошибок Kerberos возникает из-за того, что имя ИЛИ имя участника-службы не установлено или установлено правильно для требуемой службы. Cnames не работают, кстати, если вы не отключите строгую проверку имен, и даже тогда они не будут работать при некоторых обстоятельствах, поэтому я предлагаю вам держаться подальше от них, по крайней мере, во время диагностики. Но, честно говоря ... САМЫЙ ЛУЧШИЙ подход к разгадке подобных вещей (поскольку журналы Windows и Curb не так полезны) - это использовать Wireshark. вы увидите переговоры, и вы увидите, почему они терпят неудачу, какие попытки и т. д. Кроме того, если вы включите журналы «аналитики и отладки» в средстве просмотра событий, вы получите дополнительные журналы отладки для Curb, которые вы можете включить, которые немного более полезны . Тем не менее ... Wireshark всегда твой друг, имхо!

Была такая же ошибка, и я пробовал много разных решений. Помогло использование явный IPv4-адрес вместо доменного имени.

В моем случае у меня было зарегистрировано HTTP / SPN для объекта, принадлежащего НЕ сервер. Однако я не смог найти, кому он принадлежит, потому что инструмент SETSPN.exe не показывает, какой контейнер (или объект) владеет SPN. Я использовал следующий сценарий PowerShell, чтобы найти владельца SPN. После того, как я удалил SPN и воссоздал его с сервером в качестве владельца (с помощью инструмента SETSPN.exe), я ждал 30 минут, пока все контроллеры домена синхронизируются, и затем все заработало.

# 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 ""
}

Это может произойти при наличии повторяющихся имен ServicePrincipalNames, что является допустимым сценарием, но, к сожалению, сбивает с толку WinRM.

Например, рассмотрим учетную запись службы appPoolAccount и сервер myWebServer, оба объекта в Active Directory будут иметь свойство ServicePrincipalName, содержащее одну и ту же строку HTTP / myWebServer. ServicePrincipalName на myWebServer будет немного отличаться, потому что это будет HTTP / myWebServer: 5985

Наличие (почти) повторяющихся имен ServicePrincipalNames приведет к сбою WinRM с ошибкой Kerberos в вопросе.

Чтобы обойти проблему, вы можете указать Invoke-Command включить порт при поиске ServicePrincipalName, например:

### Tell WinRM to include the port in the SPN
Invoke-Command -ComputerName myWebServer -ScriptBlock {Get-Process} -SessionOption (New-PSSessionOption -IncludePortInSPN)

У меня тоже была проблема с Kerberos. Оказалось, что доверительные отношения между доменом и сервером нарушены. Как только я исправил это с помощью PowerShell, все снова стало нормально.