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

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

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

Я не смог добавить комментарий (Новая работа, новый аккаунт, никаких очков) к сообщению, которое я хотел, так что я отвечаю. Причина, по которой использование IP помогает/решает проблему, заключается в том, что при использовании IP не используется Kerberos. Kerb пытаются использовать только тогда, когда используется FQDN (или NBT имя, но это только потому, что оно добавляет доменное имя, делая его fqdn в любом случае). Вообще говоря, большинство ошибок Kerberos связано либо с именем ИЛИ SPN не устанавливается или устанавливается правильно для службы, которую вы требуете. Имена не работают btw, если вы не отключите строгую проверку имен и даже тогда они не будут работать при некоторых обстоятельствах, поэтому я советую вам держаться от них подальше, по крайней мере, во время диагностики. Но честно говоря... ЛУЧШИЙ подход к разгадке такого рода вещей (потому что журналы Windows и Kerb не так уж и полезны) - это использование Wireshark. Вы увидите переговоры и увидите, почему он не работает, что он пытается сделать и т.д. К тому же, если вы включите "аналитические и отладочные" журналы в Event viewer, вы получите дополнительные отладочные журналы для Kerb, которые вы можете включить, что немного более полезно. Тем не менее... Wireshark - это всегда ваш друг imho!

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

Это может произойти при наличии повторяющихся имен 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)

В моем случае у меня было HTTP/SPN, зарегистрированное для объекта, который принадлежал НЕ серверу. Однако я не смог найти, кому он принадлежит, поскольку инструмент SETSPN.exe не показывает, какой контейнер (или объект) владеет именем участника-службы. Я использовал следующий сценарий PowerShell, чтобы найти владельца имени участника-службы. После того, как я удалил имя участника-службы и воссоздал его с сервером в качестве владельца (с помощью инструмента 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 ""
}