Ошибка разрешения целевого компьютера kerberos

Ошибка разрешения целевого компьютера kerberos

Просматривал журнал на своем рабочем компьютере с Windows 7 и наткнулся на любопытную ошибку. (у коллеги на компьютере с Windows XP таких ошибок нет)

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера PC1$. Использовалось конечное имя cifs/PC2.domain.ru. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером.

Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (DOMAIN.RU) отличен от домена клиента (DOMAIN.RU), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Самое интересное, что PC1 и PC2 находятся в другой подсети и почему эта ошибка отобразилась в моем журнале – непонятно!

В интернете пишут, что ошибка возникает из-за DNS, в котором могут быть прописаны разные узлы с одним и тем же IP-адресом. Но у меня в DNS было все нормально, записей с одним IP не было.

Решил глянуть, что происходит в WINS. Мысль оказалась верной. При поиске по IP адресу, вылезло сразу 3 машины на один айпи. Потер все совпадающие записи с сервера WINS и надеюсь, что ошибки пропадут.

Я настраиваю лабораторную среду Windows. У этого есть контроллер домена Win2012R2 (srv001), и я хотел бы добавить еще один сервер Win2012R2 в домен (srv003). На самом деле все идет хорошо. Я дал новому серверу статический IP-адрес в той же подсети, что и DC, указал на нужный DNS-сервер и добавил сервер в домен.

Однако, когда я добавляю новый сервер в диспетчер сервера, я получаю ошибку Kerberos: 0x80090322. У меня довольно длинное сообщение об ошибке, которое я опубликую ниже. Я провел некоторое тестирование и узнал, что на самом деле я могу настроить удаленный сеанс Powershell на сервер с использованием проверки подлинности Kerberos:

Здесь нет проблем. Я набрал Enable-PSRemoting на удаленном сервере, там проблем нет.

Почему серверу не нравится мой новый сервер? Тем более, что можно настроить удаленный Powershell, используя тот же протокол, о котором говорит диспетчер сервера.

Сообщение об ошибке, которое относится к коду ошибки 0x80090322:

Ошибка обновления конфигурации со следующей ошибкой: метаданные не удалось получить с сервера из-за следующей ошибки: WinRM не может обработать запрос. При использовании проверки подлинности Kerberos произошла ошибка с кодом ошибки 0x80090322: произошла неизвестная ошибка безопасности. Возможные причины:

  1. Недопустимое имя пользователя или пароль.
  2. Kerberos используется, если не указан метод аутентификации и имя пользователя.
  3. Kerberos принимает имена пользователей домена, но не локальные имена пользователей.
  4. Имя участника службы (SPN) для имени и порта удаленного компьютера не существует.
  5. Клиент и удаленные компьютеры находятся в разных доменах, и между двумя доменами нет доверия.

После проверки вышеуказанных проблем попробуйте выполнить следующее:

  1. Проверьте средство просмотра событий событий, связанных с аутентификацией.
  2. Измените метод аутентификации; добавьте целевой компьютер в настройку конфигурации WinRM TrustedHosts или используйте транспорт HTTPS. Обратите внимание, что компьютеры в списке TrustedHosts могут быть не аутентифицированы.
  3. Для получения дополнительной информации о конфигурации WinRM запустите следующую команду: winrm help config.

Чтобы вернуться к пронумерованным элементам сообщения об ошибке:

  1. Для этого я использую учетную запись администратора домена.
  2. Не знаю, как это изменить в диспетчере сервера, поэтому я полагаю, что это должно быть сделано по умолчанию.
  3. Я запускаю внутри домена, запустив диспетчер сервера в качестве администратора домена.
  4. На сервере фактически есть следующие SPN, которые я не коснулся:
  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
Читайте также:  Как восстановить поврежденные файлы на флешке
  • Оба компьютера находятся в одном домене.
  • На клиентской машине нет событий.
  • Не нужно делать это.
  • Во второй части статьи мы перейдем к более глубокому изучению принципов работы ограниченного делегирования Kerberos на основе ресурсов с дополнительными техническими деталями и поэтапно рассмотрим процесс обработки сообщений

    В статье «Упрощенное ограниченное делегирование Kerberos в Windows Server 2012, часть 1», опубликованной в Windows IT Pro/RE № 4 за 2013 год, я начал рассказывать о механизме ограниченного делегирования Kerberos на основе ресурсов, который реализован в Windows Server 2012. Также были рассмотрены целевые сценарии, для которых предназначается ограниченное делегирование Kerberos на основе ресурсов, и представлен краткий обзор технологии. .

    Технические подробности

    Ограниченное делегирование позволяет указать те внутренние службы, для которых внешняя служба может запрашивать билеты от имени другого пользователя. Такое поведение проще всего понять, анализируя действия по проверке подлинности как последовательность двух событий: клиент проходит проверку во внешней службе, а внешняя служба проходит проверку во внутренней.

    Проверка подлинности «клиент — внешняя служба». Проверка подлинности между клиентом Kerberos и внешним сервером не меняется при использовании ограниченного делегирования на основе ресурсов. Клиент Kerberos запрашивает билет службы из локального центра распространения ключей Key Distribution Center (KDC) для целевого имени участника-службы service principal name (SPN).

    Если целевая служба находится в том же домене, то KDC выдает билет службы и сеансовый ключ клиенту Kerberos в сообщении TGS-REP. Если целевая служба находится вне текущего домена, KDC выдает ссылочный билет TGT с использованием межобластного сеансового ключа доверительного отношения в TGS-REP. Клиент Kerberos следует по ссылке, как обычно при проверке подлинности в ресурсе вне домена (через доверительное отношение).

    Проверка подлинности «внешняя служба — внутренняя служба». Проверка подлинности внешней службы (клиент Service-for-User, S4U) во внутренней службе отличается при использовании ограниченного делегирования на основе ресурсов. Для делегирования требуется, чтобы компьютер, на котором выполняется внешняя служба, работал с Server 2012, так как службы, функционирующие на версиях Windows, предшествующих Windows 8 и Server 2012, не обеспечивают ограниченного делегирования на основе ресурсов; в ранних версиях Windows нет следования по ссылкам из Service-for-User-to-Proxy (S4U2Proxy) TGS-REQ через границы домена.

    Во время проверки подлинности между внешней и внутренней службами внешняя запрашивает у KDC билет службы от имени другого пользователя. В этом обмене используется расширение S4U2Proxy (то есть ограниченное делегирование). Клиент Kerberos успешно представляет билет службы внешней службе. Внешняя служба олицетворяет удостоверение, представленное в билете службы, и пытается выполнить проверку подлинности во внутренней службе с именем SPN. Такая попытка приводит к тому, что внешняя служба создает S4U2Proxy TGS-REQ для KDC в домене внешнего сервера. В запрос входят целевое имя SPN, находящееся в другом домене, и билет службы, используемый для проверки подлинности во внешней службе. Возвращенный TGS-REP зависит от отвечающего KDC.

    Поведение внешнего KDC

    На микроуровне ограниченное делегирование связано со многими решениями и операциями обмена информацией, которые начинаются с обращения клиента во внешний KDC.

    KDC в версиях, предшествующих Server 2012. Получив S4U2Proxy TGS-REQ для целевого SPN вне своего домена, KDC возвращает внешней службе ошибку Kerberos KDC_ERR_BADOPTION (13) в сообщении TGS-REP. Такой ответ объясняется неспособностью KDC в версиях, предшествующих Server 2012, предоставить ссылочный TGT для S4U2Proxy TGT_REQ для целевого SPN, находящегося вне собственного домена. До появления Server 2012 ограниченное делегирование между доверительными доменами и лесами было невозможно.

    KDC версии Server 2012. KDC получает S4U2Proxy TGS-REQ и определяет, находится ли целевое имя SPN в его домене. В данном сценарии целевое имя SPN находится в другом домене. Поэтому KDC версии Server 2012 — обеспечивающий ограниченное делегирование на основе ресурсов — предоставляет ссылочный TGT для внешней службы в TGS-REP.

    Поведение внешней службы при получении TGS-REP

    Внешняя служба получает TGS-REP из KDC. Следующее действие внешней службы зависит от ответа, полученного KDC из S4U2Proxy TGS-REP.

    TGS-REP от KDC версий, предшествующих Server 2012. Внешняя служба получает сообщение TGS-REP в ответ на S4U2Proxy TGS-REQ. Ответ от KDC — ошибка Kerberos ERROR — KDC_ERR_BADOPTION (13). Внешняя служба функционирует на сервере Server 2012, члене домена. Server 2012 — клиент Kerberos, учитывающий возможности ограниченного делегирования между доменами; поэтому, когда внешняя служба получает S4U2Proxy TGS-REP с ошибкой KDC_ERR_BADOPTION (13), ей известно, что, возможно, установлена связь с KDC, не поддерживающим ограниченное делегирование между доменами. В ответ сервер, член домена Server 2012, на котором выполняется внешняя служба, пытается обнаружить контроллер домена (DC) Server 2012. После того, как контроллер домена обнаружен, член-сервер, функционирующий на внешней службе, отправляет то же сообщение S4U2Proxy TGS-REQ в контроллер домена Server 2012.

    Читайте также:  Сервер smtp не настроен обратитесь к администратору

    TGS-REP от KDC Server 2012. Внешняя служба получает TGS-REP в ответ на S4U2Proxy TGS-REQ. Ответ от KDC — ссылочный TGT на домен, ответственный за проверку подлинности для целевого SPN. Server 2012 — клиент Kerberos, учитывающий возможности ограниченного делегирования между доменами. Сервер, член домена, на котором выполняется внешняя служба, следует по ссылкам к домену, указанному в ссылочном TGT. Важное замечание: при переходе по доверительным отношениям с использованием ограниченного делегирования на основе ресурсов компьютер должен пройти проверку подлинности. Поэтому предполагается, что компьютер выполнит TGS-REQ для TGT в каждом домене, а также первый S4U2Proxy TGS-REQ, выполненный внешней службой. Ссылочный процесс TGS-REQ продолжается до тех пор, пока не будет обнаружен контроллер домена Server 2012 в домене, в котором находится целевое имя SPN.

    Поведение внутреннего KDC

    Внутренний KDC получает S4U2Proxy TGS-REQ из внутренней службы. В состав TGS-REQ входит доказательный билет, представляющий собой билет службы от начальной проверки подлинности во внешней службе, а также межобластной ссылочный TGT, полученный в ходе предшествующего обмена с KDC.

    Сначала KDC определяет, находится ли целевое имя SPN в его домене. Если нет, KDC создает ссылочный TGS-REP, как описано выше. Либо целевое имя SPN может существовать в текущем домене. В этом случае KDC может предоставить билет службы для целевой службы и ответить напрямую, а не ссылкой на другой домен. Затем KDC читает атрибут msDS-AllowedToActOnBehalfOfOtherIdentity в субъекте безопасности, зарегистрированном для целевого внутреннего SPN. Если атрибут пуст, контроллер домена Server 2012 будет использовать традиционную логику ограниченного делегирования (msDS-AllowedToDelegateTo [A2D2]). Если у msDS-AllowedToActOnBehalfOfOtherIdentity есть значение, KDC олицетворяет субъект безопасности, с которым работает внешняя служба и выполняет проверку доступа с использованием дескриптора безопасности, сохраненного в атрибуте msDS-AllowedToActOnBehalfOfOtherIdentity.

    В случае ошибки при проверке доступа KDC использует традиционную логику ограниченного делегирования (A2D2), чтобы выяснить, разрешено ли ограниченное делегирование. Успешная проверка доступа означает, что внутренняя служба разрешает внешней службе запросить билет от имени других субъектов безопасности, используемых при проверке подлинности во внешней службе. KDC формирует билет службы для внутренней службы с использованием имени клиента из доказательного билета и возвращает билет службы и сеансовый ключ для внешней службы, чтобы задействовать его при проверке подлинности во внутренней службе как пользователю.

    Поведение KDC с традиционным ограниченным делегированием и без него

    Если внутренний сервер настроен на использование традиционного ограниченного делегирования (msDS-AllowedToDelegateTo — A2D2), которое должно размещаться в том же домене, то для проверки подлинности можно использовать KDC Server 2012 или KDC, функционирующий с предыдущей версией Windows.

    Поведение центров KDC, отличных от Server 2012. Центры KDC с предшествующими версиями Windows работают так же, как традиционное ограниченное делегирование. Если режим A2D2 не настроен, а внутренняя служба находится в текущем домене, KDC возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND. Если A2D2 не настроен, а внутренняя служба находится другом домене, KDC возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND.

    Если A2D2 настроен, значение атрибута не соответствует внутренней службе, а внутренняя служба находится в текущем домене, KDC возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND. Если внутренняя служба находится в другом домене, KDC возвращает KRB-ERR-POLICY состояние STATUS_CROSSREALM_DELEGATION_FAILURE.

    Поведение центров KDC Server 2012. Если A2D2 не настроен, а внутренняя служба находится в другом домене, KDC Server 2012 возвращает ссылочный TGT. Если A2D2 не настроен, а внутренняя служба находится в текущем домене, ограниченное делегирование на основе ресурсов не настроено на объекте субъекта безопасности, KDC Server 2012 возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND.

    Читайте также:  Почему не обновляются драйвера на windows 7

    Если режим A2D2 настроен, в атрибуте нет значения внутреннего имени SPN, внутренняя служба находится в текущем домене, а ограниченное делегирование на основе ресурсов не настроено на объекте субъекта безопасности, то KDC Server 2012 возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND. Если внутренне имя SPN находится в другом домене, KDC Server 2012 возвращает ссылочный TGT.

    Этапы процесса обработки сообщений

    Изучив основы, можно рассмотреть шаги обработки сообщений, чтобы наглядно представить себе совместную работу всех элементов. Не беспокойтесь, если не удастся понять все с первого раза. Новый подход существенно отличается от прежнего механизма делегирования. Если материал кажется очень простым, значит, вы делаете первые шаги в его освоении. Управлять процессом просто, но для понимания внутренних механизмов требуется время, чтобы разобраться и вникнуть.

    Чтобы уменьшить количество видимых шагов до обмена сообщениями в ходе ограниченного делегирования на основе ресурсов, необходима успешная проверка подлинности клиента во внешней службе (см. рисунок).

    Рисунок. Схема успешной аутентификации клиента на внешнем сервере
    1. Внешняя служба отправляет S4U2Proxy TGS-REQ в KDC в домене root.fabrikam.com, запрашивая билет службы для внутренней службы от имени пользователя. TGS-REQ содержит TGT внутренней службы, пересылаемый билет службы клиента для внешней службы, или доказательный билет, и параметр KDC — cname-in-addl-tkt. Если KDC в root.fabrikam.com возвращает KRB-ERR-BADOPTION, то внешняя служба обнаруживает контроллер домена Server 2012 и повторно задействует TGS-REQ.
    2. KDC в root.fabrikam.com определяет, что внутренняя служба не находится в root.fabrikam.com, и возвращает ссылочный TGT для corp.contoso.com к внешней службе от имени пользователя. Поле cname в билете использует имя внешней службы, а поле crealm — имя домена внешней службы.
    3. Внешняя служба должна пройти проверку подлинности во внутреннем домене, чтобы следовать по ссылке от имени пользователя. Внешняя служба отправляет TGS-REQ от своего имени центру KDC в root.fabrikam.com, чтобы запросить билет службы для внутренней службы.
    4. KDC в root.fabrikam.com определяет, что внутренняя служба не находится в root.fabrikam.com, и возвращает сообщение TGS-REP, содержащее ссылочный TGT для corp.contoso.com.
    5. Внешняя служба отправляет TGS-REQ, для себя, запрашивая билет службы для внутренней службы.
    6. KDC в corp.contoso.com отправляет TGS-REP, содержащее билет службы для внутренней службы, который используется внешней службой.
    7. Внешняя служба обнаруживает контроллер домена Server 2012 в corp.contoso.com и отправляет S4U2Proxy TGS-REQ в KDC в домене corp.contoso.com, запрашивая билет службы для внутренней службы от имени пользователя, присутствующего в доказательном билете. Запрос содержит ссылочный TGT внешней службы, дополнительные билеты (ссылочный TGT S4U) и параметр cname-in-addl-tkt.
    8. KDC в домене corp.contoso.com извлекает информацию об учетной записи из AD с использованием SamIGetUserLogonInformation, олицетворяет внешнюю службу и выполняет проверку доступа с помощью дескриптора безопасности в атрибуте msDS-AllowedToActOnBehalfOfOtherIdentity. Если проверка доступа завершается неудачно, KDC возвращает KRB-ERR-BADOPTION; в противном случае KDC возвращает билет службы в TGS-REP.
    9. Внешняя служба представляет билет службы, запрошенный от имени пользователя, внутренней службе, передавая AP-REQ.
    10. Внутренняя служба возвращает AP-REP, если требуется обоюдная проверка подлинности.

    Смена протокола (S4U2Self)

    Расширение смены протокола для Kerberos не требует контроллера домена Server 2012. Поэтому клиенты S4U Windows 8 и Server 2012 не пытаются обнаружить контроллер домена Server 2012 для обслуживания этих запросов.

    Внешним серверам необходимо определить местонахождение контроллеров домена Server 2012, когда начальный S4U2Proxy TGS-REQ возвращает ошибку KRB-ERR-BADOPTION или KRB-ERR-POLICY. Для этого клиент S4U использует API-интерфейс DsGetDCName общедоступной службы каталогов, который направляет вызов RPC к контроллеру домена. Конкретный вызов содержит флаг DS_DIRECTORY_SERVICE_8_REQUIRED, который указывает, что API должен возвратить только контроллеры домена Server 2012.

    На этом я завершаю рассказ об ограниченном делегировании на основе ресурсов, и вы можете видеть, каким образом оно облегчает труд администратора. В Server 2012 настройка ограниченного делегирования упрощена. Устраняется необходимость в регистрации дублированных имен SPN на нескольких внешних компьютерах, управление передается владельцу ресурса, а не владельцу внешней службы и администратору домена. Кроме того, ограниченное делегирование на основе ресурсов может применяться между доверенными доменами и лесами — возможность, о которой давно и настойчиво просили потребители.

    Поделитесь материалом с коллегами и друзьями

    Ссылка на основную публикацию
    Открытые порты web proxy 80 как закрыть
    Пройдя наш тест "безопасность вашего компьютера" вы обнаружили, что ваша система имеет один или несколько открытых портов и незнаете как...
    Округление до сотых vba
    Очень часто при создании алгоритмов подсчета тех или иных значений полученные результаты имеют значение десятичной дроби с большим количеством знаков...
    Описать 5 антивирусных программ таблица
    Рассмотрим некоторые антивирусные программы. Eset NOD32 (Словакия). NOD 32 Antivirus System от Eset Software обеспечивает хорошо сбалансированную безупречную защиту персональных...
    Отмененный звонок в telegram
    Зачем приложение Телеграм, когда есть ВЕБ ТЕЛЕГРАМ?! Встроены прокси сервера для обхода блокировки! Позволяет общаться через браузер! Можно незаметно читать...
    Adblock detector