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

Изучив основы, можно рассмотреть шаги обработки сообщений, чтобы наглядно представить себе совместную работу всех элементов. Не беспокойтесь, если не удастся понять все с первого раза. Новый подход существенно отличается от прежнего механизма делегирования. Если материал кажется очень простым, значит, вы делаете первые шаги в его освоении. Управлять процессом просто, но для понимания внутренних механизмов требуется время, чтобы разобраться и вникнуть. Чтобы уменьшить количество видимых шагов до обмена сообщениями в ходе ограниченного делегирования на основе ресурсов, необходима успешная проверка подлинности клиента во внешней службе.
1. Внешняя служба отправляет S4U2 Proxy TGS-REQ в K.DC в домене 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 и отправляет S4U2 Proxy TGS-REQ в KDC в домене corp.contoso.com, запрашивая билет службы для внутренней службы от имени пользователя, присутствующего в утвержденном билете. Запрос содержит ссылочный TGT внешней службы, дополнительные билеты (ссылочный TGT S4U) и параметр cname-in-addl-tkt.
8. KDC в домене corp.contoso.com извлекает информацию об учетной записи из AD с использованием SamlGetUserLogonlnformation, олицетворяет внешнюю службу и выполняет проверку доступа с помощью дескриптора безопасности в атрибуте msDS - AllowedToActOnBehairotXDtherldentity. Если проверка доступа завершается неудачно, KDC возвращает KRB-ERR-BADOPTION; в противном случае KDC возвращает билет службы в TGS-REP.
9. Внешняя служба представляет билет службы, запрошенный от имени пользователя, внутренней службе, передавая AP-REQ.
10. Внутренняя служба возвращает АР-REP, если требуется обоюдная проверка подлинности.
Смена протокола (S4U2 Self)
Расширение смены протокола для Kerberos не требует контроллера домена Server 2012. Поэтому клиенты S4U Windows 8 и Server 2012 не пытаются обнаружить контроллер домена Server 2012 для обслуживания этих запросов.
Внешним серверам необходимо определить местонахождение контроллеров домена Server 2012, когда начальный S4U2 Proxy TGS-REQ возвращает ошибку KRB-ERR-BADOPTION или KRB-ERR-POLICY. Для этого клиент S4 U использует API-интерфейс DsGetDCName общедоступной службы каталогов, который направляет вызов RPC к контроллеру домена. Конкретный вызов содержит флаг DS_DIRECTORY_SERVICE_8_ REQUIRED, который указывает, что API должен возвратить только контроллеры домена Server 2012. На этом я завершаю рассказ об ограниченном делегировании на основе ресурсов, и вы можете видеть, каким образом оно облегчает труд администратора. В Server 2012 настройка ограниченного делегирования упрощена. Устраняется необходимость в регистрации дублированных имен SPN на нескольких внешних компьютерах, управление передается владельцу ресурса, а не владельцу внешней службы и администратору домена. Кроме того, ограниченное делегирование на основе ресурсов может применяться между доверенными доменами и лесами - возможность, о которой давно и настойчиво просили потребители.

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

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

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

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