Файл: Сервер аутентификации Kerberos ( Цербер).pdf

2.3 Аутентификация за пределами домена

Функция центра распределения ключей можно разделить на две группы, а именно: служба выдачи мандатов, которая генерирует сеансовые мандатыи и служба выдачи TGT мандатов. Такое разделение позволяет использовать рассматриваемый протокол за пределами основного домена, то есть клиентская машина, получившая TGT мандат из центра распределения ключей одного домена получает возможность воспользоваться им для получения сеансовых мандатов в KDC другого домена.

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

Далее рассмотрим процесс при котором пользователь с учетной записью в домене «Москва» запрашивает доступ с службе из домена «Саратов». Клиент Kerberos на машине пользователя направляет запрос в KDC своего домена, где просит выдать сеансовый мандат на сервер расположенный в другом домене. Центр KDC, аточнее её служба выдачи мандатов проверяет свою базу данных абонентов безопасности и видит, что такого сервере среди абонентов нет, поэтому служба отправляет клиенту не сеансовый мандат, а мандат переадресации (referal ticket),который из себя представляет TGT мандат зашифрованный междоменным ключом, общим для центров KDC доменов «Москва» и «Саратов». Клиент же, по получении этого мандата переадресации, использует его для подготовки следующего запроса на на сеансовый мандат. Отличие в том, что в этот раз запрос направляется в KDC того домена, где находится абонентская запись искомого сервера, в нашем случае домена «Саратов». Его служба выдачи мандатов принимает попытку расшифровать TGT мандат из домена «Москва» при помощи своей копии междоменного ключа, при успехе этой попытки, KDC домена «Саратов» отправляет обратившемуся клиенту сеансовый мандат для доступа к соответствующей службе своего домена.

Схема переадресации запросов может быть порядочно усложнена в таких сетях, где развернуто более двух доменов. Казалось бы, всё просто, в теории центр KDC каждого домена может наладить связь с каждым центром KDC других доменов, договорившись каждым о б использовании индивидуального междоменного ключа. Однако не сложно представить насколько количество и сложность таких связей возрастет и на сколько сложно будет выстроенно управление ими. Kerberos имеет решение и для этой проблемы: клиент каждого домена можует получить доступ к серверу другого домена через один и более промежуточный сервер, каждый из которых выдаст ему мандат переадресации.

Для более наглядного описания обратимся к уже известным нам доменам «Москва» и «Саратов», а так же добавим третий домен «Арвендейл». В центре KDC домена «Москва» отсутствует междоменной ключ для KDC домена «Саратов», но центры распределения ключей обоих доменов уже установили связь с доменом «Арвендейл». Когда клиентской машине из домена «Москва» понадобится сервер из домена «Саратов», её запрос будет пару раз переадресован. Во-первых, клиент сначала обратится в центр KDC своего домена, далее пакет попадет на промежуточный сервер «Арвендейл», а уже затем пакет направляется в KDC домена «Саратов», которому известен сеансовый ключ нужного сервера, то есть выходит, что клиент посылает сеансовый мандат три раза в три разные службы KDC. Пошагово вышеописанный процесс выглядит так:

1. Пользователь-клиент запрашивает у центра распределения ключей домена «Москва» мандат на доступ к службе сервера «Саратов». Служба KDC «Московоского» домена возвращает клиенту мандат переадресации в KDC домена «Арвендейл», зашифрованный общим для доменов «Москва» и «Арвендейл» междоменным ключом.
2. Клиент направляет запрос в службу KDC домена «Арвендейл» с вопросом о выдаче сеансового мандата на доступ к серверу домена «Саратов». Центр распределения ключей домена «Арвендейл» возвращает клиенту мандат переадресации в KDC домена «Саратов», зашифрованный междоменным ключом, общим для доменов «Арвендейл» и «Саратов»
3. В итоге клиент обращается в KDC домена «Саратов» с запросом на сеансовый мандат для доступа к серверу, находящемуся в зоне ответственности этого домена. Центр KDC домена «Саратов» отправляет в адрес клиента сеансовый мандат на доступ к нужному серверу.

2.4 Подпротоколы.

2.4.1 AS Exchange

Далее будет уместно разобрать три существующих подпротокола протокола Kerberos. Первый из них применяется центром распределения ключей для отправки клиенту сеансового ключа регистрации и TGT мандата. Называется он Authentication Service Exchange (обменный сервис аутентификации), так же допустимо применение в сокращенной форме – AS Exchange. Следующий, второй подпротокол использующийся для отправки служебных сеансовых ключей и сеансовых ключей самого центра KDC называется Ticket-Granting Service Exchange (служба обмена мандатами). Последний, третий подпротокол, Client/server Exchange (клиент-серверный обмен) нужен клиенту для пересылки сеансового мандата доступа к сервисам.

Для лучшего понимания схемы взаимодейтсвия подпротоколов следует обратиться к нашим старым знакомым в следуещем качестве: Алёна – пользователь сети, а Стив – сервер.

Рисунок 5. AS Exchange подпротокол.

Центр KDC получая запрос KRB_AS_REQ, ищет в своей базе данных соответствующий учетной записи Алёны её долговременный ключ, расшифровавыет с помощью него блок данных предварительной аутентификации и проверяет метку времени, хранящуяся в нем. При успешной провереке, служба KDC делает закономерный вывод, что информация в блоке предварительной аутентификации была зашифрована долговременным ключом Алёны, что значит это информация поступила от клиента, имя которого содержится в первой части блока. После успешной проверки личности Алёны, центр распределения ключей формирует удостоверение, подтверждающее, что клиентская программа протокола Kerberos на её машине имеет право направить запрос в службу выдачи мандатов. Этот процесс состоит из двух шагов:

1. Центром KDC формирует сеансовый ключ регистрации и шифрует его с помощью долговременного ключа Алёна.
2. Центр формирует TGT мандат включая туда еще одну копию сеансового ключа регистрации, данные авторизации Алёны. Вместе с этой информацией KDC шифрует TGT мандат своим долговременным ключом. Затем зашифрованный сеансовый ключ регистрации вместе с TGT мандатом собирается в пакет Kerberos Authentication Service Reply (KRB_AS_REP) – ответ службы аутентификации Kerberos, который отправляется клиенту.

Получив это сообщение, клиент применяет свой долговременный ключ

для расшифровки сеансового ключа регистрации и помещает его в свою кэш-память удостоверений вместе с так же извлеченным TGT мандатом.

2.4.2 TGS Exchange

Клиентская программа Kerberos, установленная на машине Алёны, посылает запрос на получение удостоверения на доступ к службе на сервере Стив в виде сообщения KRB_TGS_REQ (Kerberos Ticket-Granting service request - запрос к сервису выдачи мандатов Kerberos) в адрес KDC. В этом сообщении заключена информация об имени пользователя, аутентификатор, зашифрованный сеансовым ключом регистрации Алёны, TGT мандат, полученный при взаимодействии по подпротоколу AS Exchange, а так же имя службы, к которой запрашивается доступ.

Рисунок 6. Подпротокол TGS Exchange

Получив блок информации KRB_TGS_REQ, центр дистрибуции ключей используя свой секретный ключ расшифровывает TGT мандат и достает из него сеансовый ключ регистрации Алёны, который в свою очередь используется для расшифровки аутентификатора Алёны. При успешной проверке её аутентификатора, центр KDC извлекает из TGT мандата регистрацинные данные Алёны и создает сеансовый ключ общий для клиента Алёны и сервера Стива. Первую копию этого сгенерированного ключа KDC шифрует сеансовым ключом регистрации Алёны, а другую копию вместе с информацией об авторизации Алёны помещает в сеансовый мандат, который шифрует долговременным ключом сервера Стива. После этих манипуляций блок информации который и является по сути удостоверением Алёны включается в пакет KRB_TGS_REP (Kerberos Ticket-Grating Service Reply – ответ службы выдачи мандатов Kerberos) и отправляется обратно на рабочую станцию Алёны. Служба Kerberos на компьютере Алёны получив этот пакет, расшифровывает его своим сеансовым ключом регистрации и получает таким образом сеансовый ключ доступа к запрашиваемой службе и помещает его в свою кэш-память удостоверений, извлекаемый далее сеансовый мандат на доступ к службе так же сохраняется в кэш-памяти.

2.4.3 CS Exchange

Сервис Kerberos, установленный на клиентской машине Алёны посылает запрос к серверу Стив, для чего направляет сообщение KRB_AP_REQ (Kerberos Application Request – запрос уровня приложений Kerberos). Это сообщение сообщение представляет собой аутентификатор Алёны, зашифрованный сеансовым ключом для сервера Стива, мандат, полученный посредством протокола TGS Exchange, а так же флаг, свидетельствующий о желании клиента произвести процесс взаимной аутентификации, причем наличие или отсутствие данного флага определяется общей конфигурацией Kerberos, по умолчанию он устанавливается без участия пользователя и без каких-либо дополнительных запросов.

Рисунок.7. Подпротокол CS Exchange

Сервер Стив, приняв сообщение KRB_AP_REQ, расшифровывает мандат и получает из него данные авторизации Алёна и сеансовый ключ, которым далее расшифровывает аутентификатор Алёны. При условии, что метка времени, содержащаяся в аунтификаторе, успешно проходит проверку, то сервер проверяет наличие флага взаимной аутентификации. При его обнаружении, Стив шифрует поле времени из аутентификатора Алёны сеансовым ключом, полученным ранее, включает полученный результат в блок данных KRB_AP_REP (Kerberos Application Reply – ответ уровня приложений Kerberos) и отправляет его обратно на машину Алёны. Клиент Kerberos рабочей машины Алёны получив пакет KRB_AP_REP расшифровывает аутентификатор Стива при помощи сеансового ключа и сравнивает извлеченную метку времени с исходной, которую направляла в первом запросе. При их совпадении делается вывод, что линк установлен с искомой службой, и можно приступать к совместной работе.

РАЗДЕЛ 3. Содержимое мандатов. Ины механизмы аутентификации. Уязвимости.

3.1 Мандаты в деталях

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

Таблица 1 – Структура мандата