Интернет-журнал "Домашняя лаборатория", 2007 №6
Шрифт:
Билет выдается клиенту для предъявления некоторому серверу. Именно этим ключом будут шифроваться данные, передаваемые между данными клиентом и сервером в текущей сессии (или пока не истекло время действия билета)
? Домен
? Имя принципала
Клиент не имеет доступа к зашифрованным полям билета. Сопоставляя Домен и Имя приципала в шифруемых и нешифруемых полях билета, сервер может заметить ситуацию, когда предъявляемый билет был выдан другому клиенту,
? Время выдачи билета
? Время
? Адреса хоста
Список IP адресов, с которых клиент может вызывать сервер
? Авторизационные данные
Эти данные используются сервером для определения прав данного клиента при вызове методов данного сервера.
Для дальнейшего изложения удобно использовать следующие обозначения:
• — секретный ключ принципала, полученный хешированием его пароля. В случае клиента, в случае сервера, в случае KDS
• — ключ сессии между и
• — данные, зашифрованные ключом
Вход пользователя в систему
Процесс входа пользователя в систему состоит из нескольких стадий
1. Ввод имени, домена и пароля
2. Запрос TGT (ticket-granting ticket) у KDS
Специальный билет TGT можно рассматривать как паспорт данного пользователя в данном домене (но принимаемый только KDS). При всех последующих обращениях к KDS в рамках данного сеанса клиентское приложение предъявляет KDS этот билет, доказывая идентичность пользователя. Запрос на получение TGT формируется автоматически и включает в себя
? Имя пользователя
? Временную метку — момент выдачи запроса, шифрованный ключом
3. Получение и ключа сессии между пользователем и KDS-
Получив запрос, KDC использует известные ему из Active Directory секретный ключ пользователя для расшифровки временной метки. Если расхождение между этой временной меткой и текущим временем по часам KDS не превышает 5 минут, делается вывод о том, что клиент аутентифицирован, т. к. только он мог воспользоваться секретным ключом для кодирования свежей временной метки.
Использование в протоколе Kerberos временной метки для аутентификации пользователя опционно и используется именно в реализации данного протокола в Windows 2000. При отсутствии временной метки аутентификация пользователя реально выполняется при попытке клиента расшифровать полученные от KDS данные, зашифрованные его секретным ключом, и получить ключ сессии между данным пользователем и KDS.
Билет TGT имеет структуру обычного билета. Заметим, что TGT зашифрован секретным ключом самого KDS. Никто кроме KDS, включая самого пользователя, не может прочитать шифрованные поля. В поле Ключ сессии этого билета содержится, что позволяет KDS не хранить ключи сессий со всеми своими клиентами. В поле Авторизационные данные содержатся взятые из Active Directory права данного пользователя и идентификаторы безопасности (SID) этого пользователя и всех групп, в которые он входит.
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 авторизирует клиента, разрешая ему выполнять определенные функции в зависимости от авторизационных данных клиента. Альтернативно, по просьбе клиента, сервер может выполнить его имперсонализацию, что означает, что сервер будет использовать права доступа к ресурсам данного клиента. Подробно эти вопросы будут рассмотрены далее.
Еще один достойный рассмотрения вопрос связан с понятием взаимной аутентификации, что означает аутентификацию не только клиента, но и сервера. Очевидна критичность этого вопроса в том случае, когда клиент собирается переслать на сервер секретную информацию (например, номер кредитной карты).