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

? Домен

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

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

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

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

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

Список 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 адрессов