- Протокол аутентификации Kerberos

Лекция 9: Протокол аутентификации Kerberos.

1. Основные концепции.
2. Диалог аутентификации.
3. Области Kerberos. Флаги мандата.
4. Kerberos V4 и V5. Стойкость Kerberos.

1. Основные концепции.

Аутентификация – одно из основных средств защиты информационных систем, наиболее важный элемент системы безопасности.

Современные информационные системы – совокупность территориально рассредоточенных компонентов. Большинству пользователей требуется доступ ко многим сервисам. Желательно, чтобы доступ могли получить только авторизованные пользователи и чтобы для серверов существовала возможность аутентифицировать запросы к сервисам.

Аутентификация – проверка подлинности. Процесс аутентификации должен быть простым для пользователей, но одновременно надежным, чтобы гарантировать безопасность системы.

Выход – в создании специальной службы аутентификации. На сегодняшний день роль фактического стандарта службы аутентификации выполняет служба, основанная на протоколе Kerberos.

Протокол Kerberos был разработан в середине 80-х годов в Массачусетском технологическом институте для сетей TCT/IP (в начале для проекта Athena). Компоненты Kerberos присутствуют в большинстве современных ОС: Windows, Solaris.

 Система  Kerberos представляет централизованную службу аутентификации (с выделенным сервером аутентификации), основной функцией которой является аутентификация пользователей для серверов и серверов для пользователей.

Kerberos использует исключительно традиционное шифрование.

Рекомендуемые материалы

Популярны 2 версии Kerberos: версии 4 и 5. В версии 5 исправлены недостатки версии 4. Версии 1-3 – рабочие.

Kerberos V5 предложена в качестве стандарта Internet  и описана в RFC 1510.

В V4 применяется DES и 56-битные ключи.

В V5 ( в Win2000 на территории США) применяется RC4 и 128-битные ключи.

Поддерживается DES в режиме CBC (сцепленных шифрованных блоков) и могут применяться другие алгоритмы шифрования.

Используется алгоритм хэширования MD5.

Система Kerberos имеет распределенную архитектуру клиент-сервер и может использовать один или несколько серверов Kerberos.

Требования, выдвигаемые разработчиками Kerberos:

1. Защита. Противник, перехватывающий сообщения в сети, не должен получить информацию, достаточную чтобы имитировать другого пользователя,
2. Надежность. Недоступность системы Kerberos должна означать недоступность службы,
3. Прозрачность. Пользователь не должен замечать процедуры аутентификации, за исключением ввода пароля.
4. Масштабируемость. Система должна поддерживать большое количество клиентов и серверов.

Цербер – персонаж классической греческой мифологии. Свирепый пес о трех головах, который охраняет ворота в царство мертвых. Трем головам Цербера в протоколах Kerberos соответствуют 3 участника: 1) клиент, 2) сервер, 3) доверенная третья сторона.

Клиентами в Kerberos могут быть пользователи и независимые программы.

Роль доверенной третьей стороны выполняет Центр Распределения Ключей.

Таким образом, Kerberos – протокол с посредником, в котором используется схема распределения ключей на основе криптографии с секретным ключом. Используется два уровня ключей. Чтобы связаться с сервером, клиенту нужен секретный сеансовый ключ (и серверу нужен этот же ключ). Этот ключ клиент может получить от ЦРК, используя для связи долговременный ключ. Долговременные ключи генерируются на основе паролей пользователей, указываемых ими при входе в систему, с помощью функций хэширования. ЦРК ведет базу данных с информацией об учётных записях всех пользователей своей области и их паролях (в хэшированном виде).

ЦРК направляет клиенту его сеансовый ключ и копию этого ключа, которую клиент должен передать серверу.

Ключи в Kerberos пересылаются с помощью мандатов, аутентификация выполняется с помощью удостоверений.

Каждый из участников соединения удостоверяет сою принадлежность фактом знания секретного ключа.

Любой клиент системы Kerberos, который хочет установить соединение с сервером, должен получить сеансовый мандат или сеансовый билет, создаваемый специально для этого соединения.

Достоинства применения мандатов:

1. Серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются у клиентов (а их может быть много). Клиент направляет мандат на сервер каждый раз, когда хочет связаться с ним.

2. У клиента нет необходимости обращаться к ЦРК перед каждым сеансом связи с сервером, так как сеансовые мандаты можно использовать многократно. У каждого мандата есть срок годности. Обычно не более 8 часов.

3. В виду того, что мандат шифруется, он не может быть изменен клиентом или противником.

Нужно понимать, что в Kerberos любое сетевое соединение начинается с аутентификации его участников. Не является исключением и соединение с ЦРК. Чтобы подключиться к определенному серверу, клиент должен иметь соответствующий мандат. Чтобы подключиться к ЦРК, клиент должен иметь мандат на получение мандатов.

На первом шаге клиент должен запросить у ЦРК сеансовый мандат и сеансовый ключ, которые будут использоваться для всех последующих соединений с ЦРК. Это выполняется один раз за сеанс работы в сети.

ЦРК выдает пользователю:

1. мандат для самого себя, его называют мандат на получение мандатов (ticket-granting ticket, TGT) или билет-запрос,

2. сеансовый ключ, с помощью которого будет шифроваться вся последующая информация между ЦРК и клиентом, его называют сеансовый ключ регистрации (logon session key).

Кроме мандатов в Kerberos используются аутентификаторы (удостоверения).

2. Диалог аутентификации.

Предыдущий диалог аутентификации имел ряд слабых мест:

1. Пароль пользователя пересылался в незашифрованном виде.

2. Не указывался срок действия мандата.

3. Нет меток даты-время.

4. Сервер должен убедиться, что пользователь, применяющий мандат, является именно тем пользователем, кому он был выдан.

5. Идентификация сервера для клиента.

Рассмотрим реальный протокол Kerberos и схему его работы.

Рис.1.Схема службы Kerberos.

В табл.2 объясняется назначение каждого из элементов протокола Kerberos, а на рис.1 показана упрощенная схема всего процесса.

AS – Authentication server –сервер аутентификации.

TGS – Ticket-Granting Server – сервер выдачи мандатов.

(1), (2) – получение мандата на получение мандата один раз для каждого сеанса пользователя.

(3), (4) – получение мандата на получение сервиса один раз для каждого типа сервиса.

(5), (6) – взаимная аутентификация клиента и сервера один раз для каждого сеанса сервиса.

Таблица 3. Обмен сообщениями по протоколу Kerberos версии 5.

K_tgs  - секретные ключи TGS и AS.

K_C – долговременный ключ, основанный на пароле пользователя (общий для пользователя и AS).

K_C,tgs – сеансовый ключ регистрации, созданный AS для секретного обмена клиента и TGS.

ID_C  - идентифицирует пользователя для AS.

ID_tgs  - идентифицирует AS о запросе пользователем доступа к TGS.

IDv - идентифицирует сервис, к которому клиент хочет получить доступ.

AD_C – сетевой адрес пользователя.

Рассмотрим

а) - Обмен службы аутентификации.

Сообщение (1) представляет собой запрос клиентом мандата на получение мандата. Запрос включает

Добавляются новые элементы по сравнению с версией 4:

1. Область_С – указывает область пользователя. (В Win2000 – имя домена).
2. Опции – это опции запрашиваемого мандата. служат для того, чтобы запросить определенные значения флагов в возвращаемом мандате.
3. Границы Времени – используются клиентом, чтобы заказать в мандате следующие установки времени:
• from – желательное время начала действия затребованного мандата,
• till - желательное время окончания действия затребованного мандата,
• rtime - желательное новое время окончания действия мандата.
4. Оказия – случайное значение, которое должно повториться в сообщении (2) для гарантии того, что ответ является новым, а не воспроизведен противником.

 Сообщение (2) возвращает мандат на получение мандата, информацию, идентифицирующую клиента и некоторый блок, шифрованный с использованием ключа шифрования, построенного на основе пароля пользователя. Этот блок включает:

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

Сам мандат включает: сеансовый ключ, информацию, идентифицирующую клиента, затребованные значения границ времени и флаги, которые указывают состояние этого мандата и требуемые опции. Эти флаги обеспечивают новые важные функциональные возможности версии 5. пока мы отложим обсуждение использования этих флагов и сконцентрируем внимание на общей структуре протокола версии 5. Мандат шифруется ключом K_tgs TGS и AS.

б) Обмен службы выдачи мандатов..

Сообщение (3) включает:

· удостоверение,

· мандат,

· имя запрашиваемого сервиса.

Кроме того, в версии 5 предусмотрены значения:

• затребованных границ времени,
• опции для мандата,
• оказия, функции которых подобны функциям соответствующих элементов сообщения (1).

Само удостоверение, по существу, то же, что и удостоверение, используемое в версии 4.

Мандат_tgs – убеждает TGS, что пользователь был идентифицирован AS.

Удостоверение_C – выполняет задачу аутентификации клиента (мандат же – способ защищенного распределения ключей)

Удостоверение может использоваться только один раз. TGS может сравнить содержащиеся в нем ID и сетевой адрес с соответствующими элементами мандата. если все совпадает, то TGS заключает, что отправителем мандата является реальный владелец мандата.

К_V – секретный ключ сервера V и TGS, им зашифрован Мандат_V.

Мандат_V – мандат многократного использования для доступа к V.

Вместе с мандатом пользователю пересылается К_C,V – сеансовый ключ для доступа к V.

ID_V в мандате убедит сервер в том, что мандат дешифрован правильно.

Е_K,V – убеждает пользователя в том, что отправителем сообщения является V (больше никто этого ключа не знает).

(6) – идентифицирует сервер для клиента.

в) Обмен аутентификации клиент/сервер: получение сервиса.

Мандат_V убеждает сервер в том, что пользователь был идентифицирован сервером TGS.

Удостоверение_С – генерируется клиентом для подтверждения того, что он является тем, кому был выдан мандат. Шифруется ключом, известным только клиенту и серверу, чтобы исключить возможность несанкционированной модификации.

ID_С и AD_С – должны совпадать со значениями в мандате.

Сообщение (4) имеет ту же структуру, что и сообщение (2), и возвращает мандат плюс информацию, требующуюся клиенту: последняя шифруется сеансовым ключом, применяемым теперь совместно клиентом и TGS.

6) Наконец, ряд новых элементов используется в версии 5 для обмена аутентификации клиента/сервера. В сообщении (5) клиент имеет возможность запросить в виде опции взаимную аутентификацию. Удостоверение включает несколько новых полей следующего вида:

• Подключ. Выбор клиентом ключа шифрования может служить для того, чтобы защитить данный конкретный сеанс приложения. Если это поле не использовать, будет применен сеансовый ключ из мандата К_С,V.
• Порядковый номер. Необязательное поле, указывающее начальный порядковый номер, который должен применяться сервером для нумерации сообщений, посылаемых клиенту в ходе данного сеанса. Сообщения нумеруются еще и для того, чтобы вовремя обнаружить воспроизведение.

Если требуется взаимная аутентификация, сервер отвечает сообщением (6).

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

В Kerberos в аутентификатор включается информация о времени отправки аутентификатора TS (метка даты-времени). Получатель (сервер) извлекает эту информации. и сравнивает с показаниями собственных часов. Если разница превыщает 5 минут, то аутентификатор считается просроченным и соединение отклоняется. Кроме того,  компьютер регистрирует все аутентификаторы, полученные в течение последних 5 минут в специальном журнале. При получении аутентификатора система просматривает журнал, если аутентификатор с данным временем ( или с большим временем) уже был получен ранее, то соединение отклоняется (аутентификатор считается ложным).

3. Области Kerberos. Флаги мандата.

Среда Kerberos должна удовлетворять следующим условиям (среда состоит из нескольких серверов Kerberos, клиентов и серверов приложений):

1. Сервер Kerberos должен иметь идентификаторы пользователей (VID) и хэшированные пароли всех пользователей в своей базе данных. Все пользователи регистрируются сервером Kerberos.
2. Сервер Kerberos и каждый сервер приложения должны иметь свой совместно используемый секретный ключ. Все серверы регистрируются сервером Kerberos.

Такая среда называется областью Kerberos. Области Kerberos в среде Win2000 совпадают с доменами.

Пользователям одной области может понадобиться доступ к серверам других областей.

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

1. Сервер Kerberos одной из взаимодействующих областей должен иметь с сервером Kerberos другой области общий секретный ключ.

Два сервера Kerberos регистрируются один в другом.

В Win2000 протокол Kerberos позволяет устанавливать между доменами двусторонние доверительные отношения.

Сервер Kerberos одной области должен доверять аутентификацию своих пользователей серверу Kerberos другой области. И наоборот.

При запросе доступа к удаленному серверу, находящемуся в другой области Kerberos, действует следующая схема:

Для получения сервиса с сервера из другой области пользователь нуждается в мандате на доступ к этому серверу.

1. Клиент пользователя сначала следует обычной процедуре получения доступа к локальному TGS.
2. Затем запрашивает мандат доступа к удаленному TGS (TGS из другой области).
3. Затем клиент может обратиться к удаленному TGS за мандатом на получение сервиса от нужного сервера в области удаленного TGS.

В схеме, показанной на рис., происходит обмен следующими сообщениями (сравните с табл.1).

Запрос на получение доступа к локальному TGS

(1) С-> AS:                         ID_C|| ID_tgs ||TS₁

(2) AS-> C:                         E_Kс[K_C,tgs || ID_tgs|| TS₂ || Срок₂ || Мандат_tgs]

Запрос доступа к удаленному TGS

(3) С-> TGS:                       ID_tgsrem|| Мандат_tgs  ||Удостоверение_С

(4) TGS-> C:                       E_Kс,tgs[K_C,tgsrem || ID_tgsrem|| TS₄ || Мандат_tgsrem]

Обращение к удаленному TGS за мандатом на получение сервиса

(5) С-> TGS_rem:                   ID_Vrem|| Мандат_tgsrem  ||Удостоверение_С

(6) TGS-> C:                       E_Kс,tgsrem[K_C,Vrem || ID_Vrem|| TS₅ || Мандат_Vrem]

(7) С-> V_rem:                       Мандат_Vrem  ||Удостоверение_С

K_C,tgs  - сеансовый ключ регистрации.

Мандат_tgs – мандат на выдачу мандатов.

Мандат_tgsrem  - мандат для доступа к удаленному TGS.

V_rem  - удаленный сервер.

Проблемой, связанной с представленным выше подходом, является то, что он не слишком эффективен в случае большого числа областей. Если число областей равно N, то потребуется N(N-1)/2 защищенных обменов ключами, чтобы каждая область Kerberos могла взаимодействовать с любой другой из этих областей.

Флаги делегирования аутентификации.

Существуют клиент-серверные приложения, в которых необходимо следующее: клиент устанавливает соединение СС сервером, который для выполнения поставленной задачи, в свою очередь, должен установить соединение с другим сервером. Например, клиент запрашивает доступ к серверу печати, который затем должен получить доступ к файлу клиента на файловом сервере.

В подобной ситуации говорят, что промежуточный сервер (выступает от имени клиента) действует в качестве агента (proxy) от имени клиента.

Протокол Kerberos V5 предоставляет возможность осуществлять подобные запросы с помощью механизма делегирования аутентификации + использование поля флагов в мандатах.

Делегирование может осуществляться двумя способами:

1. Использование прокси-мандата (билета).

 В этом случае клиент запрашивает мандат на получение мандата с установленным флагом PROXIABLE (в.1). Используя подобный мандат, клиент может запрашивать у TGS специальный прокси-мандат. В запросе клиент должет указать имя первого и второго сервера. Таким образом, создается связка клиент- 1-й сервер-2-ой сервер. В прокси-мандате будет установлен флаг PROXY. Мандат на доступ в к серверу 2 через сервер –агент (proxy) 1.

2. Перенаправление мандата.

Первому серверу перепоручаются обязанности клиента для получения сеансового мандата, нужного для соединения со вторым сервером.,

(1) Клиент отправляет запрос к AS на получение мандата, поддерживающего возможность перенаправления.

(2) В ответ AS создает мандат на получение мандата с установленным флагом FORWARDABLE = 1

(3) Сервер 1 получает от клиента мандат на получение мандата с установленным флагом FORWARDABLE (говорит о том, что это – переданный мандат) и сеансовый ключ, используемый для соединения клиента с TGS.

(4) Сервер 1 использует полученный (переданный) мандат для обращения к TGS, чтобы получить сеансовый мандат, нужный для соединения с другим сервером. При этом запрос сеансового мандата производится от лица клиента.

(5) Получение сеансового мандата для доступа к серверу 2. В нем устанавливается флаг FORWARDABLE, указывающий на то, что данный мандат был выдан на основании результата аутентификации.

Преимущества метода: клиенту не требуется точно знать имя второго сервера в момент соединения с первым сервером.

 Если мандат имеет установленный флаг FORWARDABLE, то этот мандат может быть предъявлен удаленному TGS. Что позволяет клиенту получить доступ к серверу 3 из другой области.

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

Флаги мандата.

В мандаты версии 5 включается поле флагов. Это обеспечивает дополнительные функциональные возможности V5 по сравнению с V4. Флаги могут принимать только два значения: 0 – отключен, 1- установлен.

1. Флаг INITIAL. Указывает на то, что мандат был выдан сервером аутентификации AS, а не сервером выдачи мандатов TGS. Когда клиент запрашивает мандат у TGS, он предъявляет мандат на получение мандата, полученный от AS. В версии 4 это было единственным способом получить мандат на использование сервиса. В версии 5 обеспечивается дополнительная возможность, когда клиент может получить мандат на использование сервиса непосредственно от AS.

2. Флаг PRE-AUTHENT (предварительной аутентификации). Указывает на то, что перед выдачей мандата сервер AS аутентифицировал клиента. Точная форма аутентификации в V5 неопределена. В версии Массачусетского технологического института предполагает предварительную аутентификацию с помощью шифровальной метки даты-времени.

Когда пользователю нужно получить мандат, ему необходимо послать серверу аутентификации AS блок предварительной аутентификации, содержащий случайное значение, номер версии и метку даты-времени, шифрованные с помощью ключа, построенного на основе пароля клиента. Сервер аутентификации AS дешифрует блок и не отправляет мандат на получение мандата, если метка даты-времени в блоке предварительной аутентификации не попадает в рамки допустимой величины отклонения времени (т. е. в интервал времени, позволяющий учесть дрейф часов и сетевые задержки).

Флаги возобновляемых мандатов(3,4,5,6).

3. Флаг RENEWABLE. сообщает TGS о том, что данный мандат может служить для получения нового мандата, срок действия которого истекает позже, т.е. включен режим периодического обновления.

Когда мандат изначально имеет долгий срок действия, у противника есть потенциальная возможность похитить его и затем использовать на протяжении достаточно длительного периода. Если с целью уменьшения этой угрозы для мандатов установить короткие сроки действия, то существенно увеличивается нагрузка на систему из-за необходимости частого получения новых мандатов. В случае мандата  на получение нового мандата клиенту необходимо:

1) либо хранить секретный ключ, что, очевидно, означает риск,

2)либо повторно запрашивать у пользователя пароль.

Компромиссная схема предполагает использование возобновляемых мандатов. Мандат с установленным флагом RENEWABLE включает два значения срока действия:

1) один для срока окончания действия данного конкретного мандата и

2) один – для крайнего возможного значения срока.

Клиент может возобновить действие мандата, предъявив его на рассмотрение TGS и запросив новое время для срока окончания действия. Если запрошенное новое время попадает внутрь границ крайнего возможного срока, TGS может выдать новый мандат с новым временем сеанса и более поздним временем окончания действия. Преимущество этой схемы в том, что TGS может отказаться обновить мандат, объявленный похищенным.

4. Флаг MAY-POSTDATE. Сообщает TGS о том, что на основании данного мандата на выдачу мандата может быть выдан сеансовый мандат отсроченный или недействительный. Если клиент получит от AS мандат на выдачу мандата с установленным флагом MAY-POSTDATE, то затем он может использовать такой мандат для того, чтобы запросить от TGS мандат с флагами POSTDATED или INVALID.

5. POSTDATED – указывает на то, что данный мандат отсрочен.

6. INVALID – мандат недействителен в данный момент и должен быть подтвержден TGS перед использованием.

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

4. Kerberos версий 4 и5. Стойкость Kerberos.

Разработка Kerberos V5 имела целью устранение ограничений V4 в двух областях:

· ограничения среды,

· технические недостатки.

Рассмотрим ограничения среды:

1. Зависимость от системы шифрования.

Версия 4 требует применения DES. В версии 5 к шифрованному тексту присоединяется идентификатор типа шифрования, поэтому может использоваться любая схема шифрования.

2. Зависимость от протокола IT.

Версия 4 требует использование IP-адресов. Другие типы адресов не распознаются. Версия 5 дает возможность использовать любые типы сетевых адресов.

3. Срок действия мандата.

В версии 4 срок действия мандата кодируется в виде 8-битового значения в единицах, соответствующих пяти минутам. Максимальный срок действия мандата оказывается равным: 2⁸ х 5 = 1280 минут (около 21 часа). Для некоторых приложений этого недостаточно. В версии 5 мандаты включают явное указание начала и окончания действия мандата, что позволяет указать любые сроки действия.

Технические недостатки версии 4. (В версии 5 предпринята попытка их устранения):

1. Двойное шифрование. Мандаты шифруются дважды – секретным ключом сервера назначения и секретным ключом клиента. Это излишнее потребление вычислительных ресурсов.
2. Шифрование в режиме РСВС. В версии 4 используется DES в нестандартном режиме распространения сцепления шифрованных блоков (Propagating Cipher Block Chaining). Этот режим уязвим в отношении атак перестановки блоков шифрованного текста. В версии 5 применяется стандартный режим шифрования СВС – режим сцепления шифрованных блоков.
3. Сеансовые ключи. каждый мандат включает сеансовый ключ, используемый клиентом для шифрования удостоверений и для связи между клиентом и сервером в ходе сеанса. Так как один и тот же мандат может использоваться повторно, то существует риск его перехвата и использования противником сеансового ключа. В версии 5 для клиента и сервера существует возможность договориться о сеансовом подключе, который действует только в одном соединении.
4. Атаки на пароль. Обе версии уязвимы в отношении атак на пароль. AS шифрует сообщения ключом, основанным на пароле клиента. Версия 5 предлагает механизм, называющийся предварительной аутентификацией, призванный затруднить атаки на пароль (Флаг PRE-AUTHENT с использованием меток времени). Пользователь редко выбирает хороший пароль. Если противник узнает пароль (каким-то образом), он сможет использовать его для получения мандатов от AS.

Стойкость Kerberos.

Использование аутентификаторов основано на предположении, что все часы сети более или менее синхронизированы.

Опасна атака с использованием «троянского коня». Протоколы Kerberos подразумевают, что программному обеспечению можно доверять. Если заменить клиентское программное обеспечение на «троянского коня», который будет записывать пароли, то защита Kerberos сводится к нулю.

Это общая проблема для любого криптографического программного пакета, работающего на незащищенном компьютере.

Реализация Kerberos V5 в OS Win 2000 Server.

Мы рассмотрели Kerberos, описанный в REC1510. Реализация в Win 2000 имеет ряд особенностей.

В среде Win 2000 протокол реализован в виде 2-х основных компонентов:

1. Служба распределения ключей (KDC).

2. Модуль обеспечения безопасности (SSP).

Обе службы Kerberos запускаются автоматически при запуске ОС и не могут быть остановлены.

1) KDC функционирует на каждом контролере домена, предоставляя любому контролеру домена возможность создавать и распространять мандаты, при этом используется служба каталогов Active Directory в качестве базы данных.

Информация, используемая протоколом Kerberos (секретный ключ, пароль) хранится в виде атрибута объекта.

Таким образом, KDC выполняет функции начальной аутентификации пользователя и распределения мандатов. KDC (Кеу Distribution Center) реализована в виде двух системных служб:

· службы аутентификации (AS),

· службы предоставления мандатов (TGS).

2)Модуль обеспечения безопасности отвечает за аутентификацию участников соединения при взаимодействии клиента с удаленной службой (реализован в виде DLL – библиотеки, SSP – Security Support Provider).

Конфигурирование политики Kerberos осуществляется при помощи Domain Security Policy, расположенной в группе программ Administrative Tools.

В дереве объектов надо выбрать пункт Kerberos Policy (внутри контейнера Account Policy)- политика учетных записей.

В панели будет отображено несколько опций Kerberos:

1. Enforce User Logon Restrictions.

Если опция установлена, то пользователь должен войти в сеть, прежде чем может запросить у службы Kerberos мандат.

2. Maximum Lifetime For Service Ticket.

Определяет максимальный срок жизни сеансового мандата (билета), выделенного службе (600 мин.=10 часов).

3. Maximum Lifetime For User Ticket.

Определяет максимальный срок жизни сеансового мандата (билета), выделенного пользователю (600 мин.=10 часов).

4. Maximum Lifetime For Renewal.

Определяет максимальный срок жизни, который может иметь обновляемый мандат, выделенный пользователю (7 дней).

5. Maximum Tolerance For Computer Clock Synchronization.

Для того, чтобы механизм аутентификации Kerberos правильно функционировал, часы на всех компьютерах должны быть синхронизированы. Администратор может с помощью данного параметра указать максимально допустимую разницу в показаниях часов (5 мин).

В Win 2000 Resource Kit поставляется утилита KerbTray, которая специально предназначена для получения информации обо всех сеансовых билетах (мандатах) Kerberos, выданных некоторому компьютеру (информация берется у КЭШа полномочий данного компьютера).

ОД содержит 4 вкладки:

На каждом компьютере (входящем в область Kerberos) с загруженным модулем обеспечения безопасности (SSP) имеется кэш полномочий для хранения сеансовых ключей и мандатов, а также криптографического ключ, полученного на основе пароля пользователя. Кэш полномочий располагается в невыгружаемой области ОП, защищенной локальной службой безопасности LSA (Local Security Authority). Когда пользователь покидает систему, кэш полномочий уничтожается.

Заключение.

Выше мы рассмотрели основные концепции протокола сетевой аутентификации Kerberos. Следует отметить, что этот протокол отличается гибкостью и эффективностью использования, а также обеспечивает повышенный уровень безопасности. С бурным развитием Интернета, локальных сетей, виртуальных частных сетей, электронной коммерции, этот протокол, похоже, является одним из тех, которые удовлетворяют всем требованиям безопасности в сегодняшней информационной среде. Поэтому неудивительно, что разработчики программного обеспечения уделяют ему повышенный интерес. Создатели протокола ведут постоянную работу по его совершенствованию, а компания Microsoft  в операционной системе Windows 2000 сделала этот протокол основным протоколом аутентификации.

Для простоты и доступности изложения в статье опущены многие моменты. Более подробную информацию по этим вопросам можно получить из дополнительных источников.