Упрощенное ограниченное делегирование Kerberos в Windows Server 2012, часть 2

В статье «Упрощенное ограниченное делегирование 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.

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.

Если режим 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 на нескольких внешних компьютерах, управление передается владельцу ресурса, а не владельцу внешней службы и администратору домена. Кроме того, ограниченное делегирование на основе ресурсов может применяться между доверенными доменами и лесами — возможность, о которой давно и настойчиво просили потребители.