Страница 197 из 372
4. Запрос билета для локальных сервисов
Для обращения к локальным сервисам на машине пользователя последнему также необходим билет для локальных сервисов, который автоматически и запрашивается у KDS с предъявлением TGT.
5. Получение билета для локальных сервисов
С этого момента пользователь может обращаться к локальным сервисам, на чем вход в систему и завершается.
Аутентификация клиента удаленным серверным приложением
Данный процесс выполняется автоматически при вызове клиентским приложением удаленного сервера. Точнее, здесь описывается процесс, выполняемый при первом обращении клиента к серверу в данном сеансе. В зависимости от выбранных клиентом и сервером уровнях аутентификации (этот вопрос будет рассмотрен позже), аутентификация клиента сервером может выполняться с различной периодичностью, от однократной при первом вызове сервера до аутентификации при получении каждого нового пакета. При повторной аутентификации выполняется только часть из рассматриваемых ниже операций.
Процесс аутентификации клиента С сервером S при первичном вызове состоит из следующих шагов:
• Клиент С посылает KDS запрос на получение билета для сервера S Этот запрос включает
♦ — билет TGT клиента С, зашифрованный ключом KDS
♦ имя сервера S
♦ — аутентификатор, зашифрованный ключом сессии для С и S
Аунтетификатор содержит текущее время и имя пользователя. Так как он зашифрован ключом сессии, никто кроме самого клиента С не может его сформировать. Временная метка усложняет попытку перехватить и послать этот запрос повторно от другого клиента (кроме того, KDS будет еще анализировать и IP адрес, с которого пришел запрос)
• KDS аутентифицирует клиента
Используя свой собственный секретный ключ KDS расшифровывает TGT клиента и извлекает из него ключ сессии. Используя ключ сессии, KDS расшифровывает аутентификатор. Аутентификация клиента считается успешной если
♦ Удалось расшифровать аунтетификатор
♦ Имя клиента из TGT совпадает с именем, указанным в аутентификаторе
♦ Временная метка из аутентификатора отличается от текущего времени по часам KDS не более чем на 5 минут
♦ Запрос пришел с одного из указанных в TGT IP адрессов
• При успешной аутентификации KDS высылает клиенту — билет для сервера S и — ключ сессии между клиентом и сервером S. Заметим, что билет Т зашифрован секретным ключом сервера S и, следовательно, клиент не сможет узнать и модифицировать его поля. В этот билет KDS включает некоторые данные из TGT (имя клиента, авторизационные данные). Кроме того, задаются флаги, срок действия билета, генерируется (случайный) и помещается в билет ключ сессии
• Клиент предъявляет серверу S билет и новый аутентификатор
• Сервер S аутентифицирует клиента, используя тот же алгоритм, что и KDS.
Используя билет Т, сервер S авторизирует клиента, разрешая ему выполнять определенные функции в зависимости от авторизационных данных клиента. Альтернативно, по просьбе клиента, сервер может выполнить его имперсонализацию, что означает, что сервер будет использовать права доступа к ресурсам данного клиента. Подробно эти вопросы будут рассмотрены далее.
Еще один достойный рассмотрения вопрос связан с понятием взаимной аутентификации, что означает аутентификацию не только клиента, но и сервера. Очевидна критичность этого вопроса в том случае, когда клиент собирается переслать на сервер секретную информацию (например, номер кредитной карты).
Возможность взаимной аутентификации появилась именно в Kerberos (в NT LAN Manager она отсутствовала). Механизм очень прост — сервер S после аутентификации клиента С высылает последнему временную метку из аутентификатора этого самого клиента, зашифрованную ключом сессии. Это доказывает клиенту, что данный сервер действительно является сервером S, т. к. для расшифровки аутентификатора ему был необходим ключ, который он мог извлечь только из билета Т, зашифрованного секретным ключом сервера S.
Реализация сервисов проверки целостности данных и шифрования трафика
Смысл и алгоритм реализации данных сервисов уже описан выше. Осталось заметить, что в качестве секретного ключа, известного только передающей и принимающей сторонам, можно использовать соответствующий ключ сессии.
Делегирование
Подробно понятие делегирования (как и понятие имперсонализация) будут рассматриваться далее. Здесь будет объяснена только его суть и описан механизм реализации делегирования в Windows 2000 Kerberos.
При имперсонализации клиента (с его согласия) сервер получает доступ к локальным ресурсам от имени данного клиента (уровень передаваемых прав доступа определяется клиентом). Однако имперсонализация не позволяет серверу делать удаленные вызовы других серверов от имени клиента. Конечно, выполняя некоторый вызов клиента С сервер S может послать удаленный вызов на другой сервер Q, но с точки зрения сервера Q вызов получен именно от сервера S, а не клиента С. Следовательно, даже если клиент С имеет особые права доступа к серверу Q, сервер S не сможет ими воспользоваться, выполнив простую имперсонализацию клиента С.
В чем причина ограниченности возможностей имперсонализации? Имперсонализация реализуется средствами конкретной операционной системы. При имперсонализации в Windows потоку в серверном процессе, выполняющему вызов пользователя, приписывается маркер доступа (access token), в котором записаны права данного пользователя, а не серверного процесса (как обычно бывает по умолчанию). Это позволяет получить от имени пользователя доступ к локальным ресурсам, т. к. при этом просто сопоставляются права доступа из маркера доступа со списком принципалов, которым разрешен или запрещен доступ к конкретному локальному ресурсу.
При удаленном доступе необходимо обеспечить такие сервисы как аутентификация, контроль целостности данных, шифрование трафика. Очевидно, что маркер доступа не содержит необходимых для этого данных. Фактически, говоря в терминах протокола Kerberos, Сервер S должен обратиться к KDS с запросом на получение билета для сервера Q, причем сервер Q при получении этого билета должен быть уверен, что получил он его от клиента С, а не от сервера S.
Данная возможность реализована в Kerberos и называется делегированием. Отметим, что делегирование отсутствует в NT LAN Manager.
Делегирование прав от клиента С серверу S осуществляется следующим образом:
• Клиент С посылает серверу S (которым он уже аутентифицирован) свой билет для KDS — и ключ сессии с KDS —
Сервер S должен иметь эти данные для того, чтобы получить от KDC билет для какого-либо другого сервера (например, Q), выданный как бы клиенту С. В отличие от сервера Q, KDS обмануть очень сложно (да и сервер Q можно обмануть только с помощью самого KDS). Поэтому от KDS и не скрывается то, что запрашивает билет сервер S, но выписать его необходимо на имя клиента С. Среди флагов билета TGT должен быть флаг forwardable, указывающий на то, что клиент С еще при первом обращении к KDS уведомил его о том, что в будущем он будет делегировать свои полномочия другим серверам (кстати, не любому серверу, а только тому, который зарегистрирован в домене как заслуживающий доверия (trusted) сервер).
• Сервер S посылает (от лица клиента С) запрос KDS на получение билета для сервера Q, в который включается, как обычно, имя сервера Q, билет и аутентификатор
Зметим, что в аунтетификатор включается имя клиента и он кодируется ключом сессии клиента С и KDS.
• KDS аутентифицирует клиента
Конечно, KDS замечает, что билет запрашивает не клиент С (вызов пришел не с того IP адреса, который указан в TGT). Однако он закрывает на это глаза в связи с тем, что в
TGT имеется флаг forwardable, и отправитель запроса знает ключ, который он мог получить только от клиента
• KDS посылает серверу S запрошенный билет, зашифрованный ключом сервера Q, и ключ сессии сервера S и сервера Q -