• Сервер S посылает (от лица клиента С) запрос KDS на получение билета для сервера Q, в который включается, как обычно, имя сервера Q, билет и аутентификатор

Зметим, что в аунтетификатор включается имя клиента и он кодируется ключом сессии клиента С и KDS.

• KDS аутентифицирует клиента

Конечно, KDS замечает, что билет запрашивает не клиент С (вызов пришел не с того IP адреса, который указан в TGT). Однако он закрывает на это глаза в связи с тем, что в

TGT имеется флаг forwardable, и отправитель запроса знает ключ, который он мог получить только от клиента

• KDS посылает серверу S запрошенный билет, зашифрованный ключом сервера Q, и ключ сессии сервера S и сервера Q -

• Далее общение сервера S и сервера Q проходит как обычное общение клиента и сервера. Заметим, что с точки зрения сервера Q он работает с клиентом С. Это позволяет серверу S делегировать полученные от клиента полномочия серверу Q и т. д. Для этого у него есть все необходимое: TGT, закодированный ключом KDS, и ключ сессии

Удаленный вызов за пределы домена

Проблема удаленного вызова за пределы домена состоит в том, что клиент должен получить билет для сервера из другого домена у KDS этого другого домена. Но наш клиент не зарегистрирован в этом новом домене и, следовательно, не может получить там TGT.

Решение проблемы — доверие двух KDS из разных доменов друг другу. Выражается это доверие в том, что эти KDS из первого и второго доменов генерируют общий только им известный секретный ключ. Краткое описание механизма аутентификации при вызове за пределы домена:

• Клиент С из первого домена, желающий получить доступ к серверу R из второго домена обращается прежде всего к KDS своего домена. Первый KDS возвращает клиенту новую версию его TGT, зашифрованную паролем и ключ сессии для общения с KDS второго домена (это ключ хранится и в новой версии TGT).

• Клиент отправляет KDS второго домена новый TGT, зашифрованный ключом и аутентификатор, зашифрованный ключом сессии клиента и второго KDS.

• Второй KDS расшифровывает TGT и, доверяя первому KDS, возвращает клиенту билет для запрашиваемого сервера из своего домена.

Модель безопасности в СОМ+

Как уже говорилось ранее, определенная независимость модели безопасности, используемой в СОМ+, достигается за счет использования интерфейса SSPI, через который СОМ+ может пользоваться услугами различных провайдеров сервиса безопасности SSP. Для определенности остановимся на SSP, представленном реализацией в Windows 2000 протокола Kerberos. Будем полагать, что все клиенты и серверы в данном домене используют этот SSP.

Как и другие сервисы СОМ+, сервис безопасности может быть использован без написания какого-либо кода, за счет администрирования. Однако возможен (и в некоторых случаях очень полезен) программный доступ к этому сервису.

Сервис безопасности весьма сложен. Для его изложения здесь выбран следующий подход. Мы рассмотрим обычный сценарий вызова клиентом некоторой функции удаленного сервера, который в процессе выполнения этого вызова будет имперсонировать клиента и использовать делегированные ему права для вызова некоторого другого сервера от лица клиента. Весь этот сложный процесс контролируется сервисом безопасности, основная функциональность которого на данном примере и будет рассмотрена.

Активация серверного приложения клиентским приложением

Для активации удаленного серверного приложения клиентское приложение может, например, вызвать функцию CoGetClassObject для получения указателя на фабрику класса (включенного в данное приложение) и последующего получения необходимо числа экземпляров данного класса. При вызове упомянутой функции клиентское приложение задает следующие входные параметры:

• CLSID нужного класса

• Тип сервера (сервер в процессе клиента, локальный или удаленный)

• Указатель на структуру COSERVERINFO, содержащей некоторые данные об удаленной машине, о клиенте, о требуемом уровне безопасности

• IID запрашиваемого интерфейса (обычно IID_IClassFactory)

Единственный выходной параметр при успешном выполнении вызова возвращает указатель на запрашиваемый интерфейс.

Самый интересный для нас параметр — указатель на структуру COSERVERINFO. Предположим для начала, что этот указатель равен NULL.