class="p1">Домен, где был выдан этот билет. Предполагается, что на контроллере домена запущен сервер Kerberos — KDS (Key Distribution Server), который и выдает все билеты в данном домене,

♦ Имя принципала

Принципалом здесь называется любая сущность, обладающая в данном домене именем и паролем. Это и все зарегистрированные в данном домене пользователи, и приложения, и машины. Все принципалы регистрируются на контролере домена в Active Directory, где в зашифрованном виде для каждого принципала хранится, в частности, его имя и хешированный пароль.

• Шифруемые поля

♦ Флаги билета

♦ Ключ сессии

Билет выдается клиенту для предъявления некоторому серверу. Именно этим ключом будут шифроваться данные, передаваемые между данными клиентом и сервером в текущей сессии (или пока не истекло время действия билета)

♦ Домен

♦ Имя принципала

Клиент не имеет доступа к зашифрованным полям билета. Сопоставляя Домен и Имя приципала в шифруемых и нешифруемых полях билета, сервер может заметить ситуацию, когда предъявляемый билет был выдан другому клиенту,

♦ Время выдачи билета

♦ Время прекращения действия билета

♦ Адреса хоста

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

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

Возможность взаимной аутентификации появилась именно в Kerberos (в NT LAN Manager она отсутствовала). Механизм очень прост — сервер S после аутентификации клиента С высылает последнему временную метку из аутентификатора этого самого клиента, зашифрованную ключом сессии. Это доказывает клиенту, что данный сервер действительно является сервером S, т. к. для расшифровки аутентификатора ему был необходим ключ, который он мог извлечь только из билета Т, зашифрованного секретным ключом сервера