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

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

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

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

Это может произойти, когда есть дубликаты 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 не показывает, какой контейнер (или объект) владеет 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 ""
}

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