Таким образом, следует помнить, что при любой аутентификации в Kerberos всегда участвуют два принципала – один соответствует пользователю, пытающемуся получить доступ к сервису, а второй – самому этому сервису. Мы не будем рассматривать более сложный механизм аутентификации, так называемый user-to-user, когда сетевой сервис не имеет собственной записи в базе данных Kerberos, а использует сертификаты пользователя, запустившего сервис. Аутентификация user-to-user могла бы быть полезна, например, для X-серверов, но и для них эта методика не получила большого распространения.

Так в общих чертах выглядит принцип работы Kerberos. Многие детали реализации протокола Kerberos при этом пришлось опустить. В частности, формат сертификата в действительности более сложен, чем описано здесь. В него входит время выдачи и срок годности сертификата, адрес компьютера, на который отсылается сертификат, и флажки, позволяющие контролировать использование сертификатов и тем самым настраивать политику безопасности внутри сектора Kerberos. Скажем, с помощью снятия флажка forwardable можно «привязать» сертификат к одному компьютеру и запретить его перемещение на другие хосты. Пример, рассмотренный в начале статьи, был бы невозможен в этом случае – после получения удаленного доступа мне каждый раз потребовалось бы вводить пароль для запроса нового TGT.

В следующем номере журнала мы перейдем к практической части и развернём инфраструктуру Kerberos в локальной сети.

Приложение

История создания Kerberos

В 1983 году была начата работа по созданию системы Athena. Работу финансировали компании IBM и DEC, и в 1987 году была выпущена первая версия протокола Kerberos (Kerberos 4). Дальнейшая эксплуатация выявила недостатки протокола, и обновленный вариант Kerberos 5 вышел в свет в 1993 году. В настоящее время 4 версия практически не используется, но в реализациях протокола от МТИ совместимость с предыдущей версией продолжает сохраняться. К 1993 году протокол Kerberos уже завоевал популярность, и многие компании, разработчики программного обеспечения стремились использовать его в своих программных продуктах. Но тут имел место юридический казус – дело в том, что в то время в США еще действовали законы, введенные еще во время холодной войны, запрещающие экспорт военных технологий. Поскольку криптографическая защита, использованная в Kerberos, классифицировалась как военная технология, это создавало препятствия для использования его в программных продуктах сторонних фирм и распространения его за пределами США. Для решения этой проблемы была выпущена версия протокола Kerberos 4, из которого была изъята вся сильная криптография. Эта реализация Kerberos получила название Bones (кости), и ограничения на ее экспорт уже не действовали. В 1997 году группа программистов из Стокгольмского Королевского университета, взяв за основу Bones, проделала обратную работу и вставила недостающую криптографическую функциональность. Вот так экспортные ограничения Соединенных Штатов способствовали развитию европейского hi-tech. Впоследствии ими же была выпущена реализация протокола Kerberos 5, получившая название Heimdal. Heimdal (Хеймдалль) – это божество из скандинавского пантеона, чьи функции состояли в охране стратегических коммуникаций, а именно – моста, разделяющего Асгард и Мидгард. Так же, как и в случае с древнегреческим прототипом Kerberos, здесь эксплуатируется образ неподкупного стража. Интересно отметить, что мотивом для программистов из Стокгольмского университета, так же как и для их коллег из МТИ, являлась задача обеспечения публичного доступа к вычислительному кластеру. Последним эпизодом из истории Kerberos стало объявление компанией Microsoft в 1999 году о поддержке Kerberos в своей будущей операционной системе NT 5.0 (впоследствии названной Windows 2000), что действительно было реализовано в качестве компонента Active Directory. В настоящее время Kerberos является промышленным стандартом удаленной аутентификации пользователей.