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

Внутренний KDC получает S4U2 Proxy TGS-REQ из внутренней службы. В состав TGS-REQ входит утвержденный билет, представляющий собой билет службы от начальной проверки подлинности во внешней службе, а также межобластной ссылочный TGT, полученный в ходе предшествующего обмена с KDC. Сначала KDC определяет, находится ли целевое имя SPN в его домене. Если нет, KDC создает ссылочный TGS-REP, как описано выше. Либо целевое имя SPN может существовать в текущем домене. В этом случае КОС может предоставить билет службы для целевой службы и ответить напрямую, а не ссылкой на другой домен. Затем KDC читает атрибут msDS - AllowedT oActOnBehairorotherldentity в субъекте безопасности, зарегистрированном для целевого внутреннего SPN. Если атрибут пуст, контроллер домена Server 2012 будет использовать традиционную логику ограниченного делегирования (msDS - AllowedToDelegateTo [А2D2]). Если у msDS - AllowedToActOnBehairotOtherldentity есть значение, KDC олицетворяет субъект безопасности, с которым работает внешняя служба, и выполняет проверку доступа с использованием дескриптора безопасности, сохраненного в атрибуте msDS - AllowedToActOn BehairafOtherldentity.
В случае ошибки при проверке доступа KDC использует традиционную логику ограниченного делегирования (A2D2), чтобы выяснить, разрешено ли ограниченное делегирование. Успешная проверка доступа означает, что внутренняя служба разрешает внешней службе запросить билет от имени других субъектов безопасности, используемых при проверке подлинности во внешней службе. KDC формирует билет службы для внутренней службы с использованием имени клиента из утвержденного билета и возвращает билет службы и сеансовый ключ для внешней службы, чтобы задействовать его при проверке подлинности во внутренней службе как пользователю.
Поведение KDC с традиционным ограниченным делегированием и без него
Если внутренний сервер настроен на использование традиционного ограниченного делегирования (msDS - AllowcdToDclcgatcTo, 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_DELEGAT10N_FAlLURE. Поведение центров KDC Server 2012. Если A2D2 не настроен, а внутренняя служба находится в другом домене, KDC Server 2012 возвращает ссылочный TGT. Если A2D2 не настроен, а внутренняя служба находится в текущем домене, ограниченное делегирование на основе ресурсов не настроено на объекте субъекта безопасности, и KDC Server 2012 возвращает KDC_ERR_BADOPTION с состоянием STATUS_NOT_FOUND. Если режим A2D2 настроен, в атрибуте нет значения внутреннего имени SPN, внутренняя служба находится в текущем домене, а ограниченное делегирование на основе ресурсов не настроено на объекте субъекта безопасности, то KDC Server 2012 возвращает KDC ERR_BADO РТIО N с состоянием STATUS_NOT_ FOUND. Если внутренне имя SPN находится в другом домене, KDC Server 2012 возвращает ссылочный TGT.

Похожие записи:

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

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

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