Kerberos

Общие сведения

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

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

Протокол Kerberos может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность использования единой учетной записи пользователя для доступа к любым ресурсам области).

Протокол основан на понятии Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).

Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.

Работая с протоколом Kerberos, необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.

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

What is Kerberos?

Kerberos is a network authentication protocol. It is designed to
provide strong authentication for client/server applications by using
secret-key cryptography. A free implementation of this protocol is
available from the Massachusetts
Institute of Technology. Kerberos is available in many commercial
products as well.

The Internet is an insecure place. Many of the protocols
used in the Internet do not provide any security. Tools to «sniff»
passwords off of the network are in common use by malicious hackers.
Thus, applications which send an unencrypted password over the
network are extremely vulnerable. Worse yet, other client/server
applications rely on the client program to be «honest» about the
identity of the user who is using it. Other applications rely on the
client to restrict its activities to those which it is allowed to do,
with no other enforcement by the server.

Some sites attempt to use firewalls to
solve their network security problems. Unfortunately, firewalls
assume that «the bad guys» are on the outside, which is often a very
bad assumption. Most of the really damaging incidents of computer
crime are carried out by insiders. Firewalls also have a significant
disadvantage in that they restrict how your users can use the
Internet. (After all, firewalls are simply a less extreme example of
the dictum that there is nothing more secure than a computer which is
not connected to the network — and powered off!) In many places,
these restrictions are simply unrealistic and unacceptable.

Kerberos was created by MIT as a solution to these network
security problems. The Kerberos protocol uses strong
cryptography so that a client can prove its identity to a server
(and vice versa) across an insecure network connection. After a
client and server has used Kerberos to prove their identity, they can
also encrypt all of their communications to assure privacy and data
integrity as they go about their business.

Kerberos is freely available from MIT, under copyright
permissions very similar those used for the BSD operating system
and the X Window System. MIT provides Kerberos in source form
so that anyone who wishes to use it may look over the code for
themselves and assure themselves that the code is trustworthy.
In addition, for those who prefer to rely on a professionally
supported product, Kerberos is available as a product from many
different vendors.

In summary, Kerberos is a solution to your network security
problems. It provides the tools of authentication and strong
cryptography over the network to help you secure your information
systems across your entire enterprise. We hope you find Kerberos as
useful as it has been to us. At MIT, Kerberos has been invaluable to
our Information/Technology architecture.

$Id: index.html,v 1.250 2020/05/22 16:25:17 ghudson Exp $

All images and text on this page are copyright MIT.

MIT Kerberos

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

Изложим основную концепцию протокола Kerberos. Предположим, что существует два человека, знающие один и тот же секрет, известный только этим двоим. Тогда любой из них сможет легко убедиться, что имеет дело со своим напарником. Для этого ему всего лишь придётся проверить, знает ли его собеседник общий секрет.

Пример.

Пункт 1. Договоренность о пароле.
Пусть Алиса общается с Бобом. При этом Боб использует информацию только тогда, когда уверен, что информация получена от Алисы. Чтобы избежать подделки — они договорились между собой о пароле, который знают только они вдвоём. При получении сообщения Боб может заключить из письма — знает ли его собеседник пароль. Если собеседнику Боба пароль известен, то можно утверждать, что его собеседником является Алиса.

Пункт 2. Возникновение проблемы передачи пароля. Теперь определим — каким же образом Алисе и Бобу показывать знание пароля. Конечно, можно просто включить пароль в текст письма. Например: «Привет, Боб. Наш пароль.». Если бы только Боб и Алиса были уверены, что их письма никто не читает — тогда можно было бы воспользоваться этим способом. Но, к сожалению, почта передается по сети, в которой работают другие пользователи, среди которых есть любопытная Ева. Ева поставила себе задачу — выяснить пароль, известный только Бобу и Алисе, при помощи которого они обмениваются сообщениями друг с другом. Теперь совершенно ясно, что нельзя указывать пароль просто в тексте письма. Значит, о пароле нельзя говорить открыто, но при этом надо дать знать собеседнику, что пароль Вам известен.

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

Пункт 4. Проблема обмена паролями. При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае с Бобом и Алисой надо понять, как они договариваются о секретном ключе для переписки друг с другом. Конечно, люди могут встретиться в парке и договориться, но ведь в сетевых переговорах участвуют и машины. Если под Алисой понимать клиентскую программу, а под Бобом — службу на сетевом сервере, то встретиться они никак не могут.
Проблема состоит ещё в том, что когда клиенту надо посылать сообщение на несколько серверов, в этом случае для каждого сервера ей придётся обзавестись отдельным ключом. А серверу тогда потребуется столько секретных ключей, сколько у него клиентов. Необходимость хранить на каждом компьютере такое количество ключей создаёт риск для всей системы безопасности.

Пункт 5. Решение проблемы обмена паролями.
Для решения этих проблем проектом «Афина» и был разработан специальный протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был назван в честь трёхголового пса, который защищал выход из царства Аида, — Цербера, или более точно — Кербера. Трём головам Цербера в протоколе соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет центр распределения ключей «Key distribution center», KDC.

Настройка Active Directory для использования групп

По умолчанию, в AD запрещено анонимным пользователям получать какую-либо информацию из каталога. Для того, чтобы squid хелпер  squid_ldap_group  имел право обращаться к каталогу Active Directory и извлекать некую информацию из доменной структуры, необходимо хелперу предоставить некие учетные данные для доступа к LDAP. Для этого я в домене создал учетку с минимально необходимыми правами (членство в группе Domain Users — Пользователи домена) (??? может будет достаточно группы Гости домена…)

Имя учетной записи в моем примере будет adsquid@AD.LOCAL, важно задать настройку запрета смены пароля и отменить ограничение времени действия пароля при создании учетной записи

Для удобства, все группы и учетные записи пользователей и компьютеров использующиеся для интеграции сервисов на Linux в инфраструктуру Kerberos я создаю в контейнере UNIXs в подконтейнерах groups, users, hosts соответственно.

Конечно же, нам необходимо создать (для примера) 2 группы пользователей. 1 — это группа, имеющая доступ в интернет без ограничения доступа (называется squid), 2 — группа, имеющая доступ только к списку избранных сайтов (называется squid-list). Можно создать сколько угодно групп с заданием разных настроек, но для примера будет достаточно 2х.

Настройка SSO на основе Kerberos в среде сервера приложений Weblogic

1. Когда зарегистрированный пользователь (РС) запрашивает ресурс из Oracle WebLogic Server (WLS), он отправляет исходный HTTP GET-запрос.
2. Сервер Oracle WebLogic Server (WLS), выполняющий код обработчика токенов SPNEGO, требует аутентификации и выдает ответ 401 Access Denied, WWWAuthenticate: Negotiate.
3. Клиент (Браузер на PC) запрашивает билет сессии из TGS / KDC (AD).
4. TGS / KDC (AD) предоставляет клиенту необходимый билет Kerberos (при условии, что клиент авторизован), завернутый в токен SPNEGO.
5. Клиент повторно отправляет запрос HTTP GET + токен Negotiate SPNEGO в заголовке авторизации: Negotiate base64 (token).
6. Проверка веб-аутентификации SPNEGO на сервере Weblogic видит заголовок HTTP с токеном SPNEGO. SPNEGO проверяет токен SPNEGO и получает информацию о пользователе.
7. После того, как Weblogic получит информацию о пользователе, он проверяет пользователя в Microsoft Active Directory / KDC. Когда процесс идентификации выполняется, Weblogic выполняет соответствующий Java-код (сервлеты, JSP, EJB и т.д.) И проверяет авторизацию.
8. Код обработчика Token Handler сервера Oracle WebLogic Server принимает и обрабатывает токен через API GSS, аутентифицирует пользователя и отвечает запрошенным URL-адресом.

Теперь перейдем к практике

• Создаем пользователя в Active Directory (срок действия пароля должен быть не ограничен)
• Устанавливаем соответствующий SPN для имени сервера WLS

верхнем регистре

• В данном случае не рассматриваем настройку авторизации WLS в AD считаем, что она работает, если нужно расписать этот пункт пишите в комментариях.
• Настраиваем SPNEGO в WLS
  Для этого необходимо перейти в WebLogic Server Administration Console
  Переходим в раздел Security Realms >myrealm >Providers и нажимаем кнопку Add
  Выбираем тип “WebLogic Negotiate Identity Assertion provider”
  Проверяем, что бы было выбрано оба параметра.
  Нажимаем кнопку Reorder и управляя стрелками выставляем последовательности типов авторизации. На первом месте должно быть установлено WebLogic Negotiate Identity Assertion provider на втором месте Provider that performs LDAP authentication (доменная авторизация)

• Перезагружаем сервер, для применения изменений в конфигурации.
• Деплоим приложение с измененным способом авторизации (новым web.xml)
• Чтобы отключить данный вид авторизации для административной консоли необходимо внести следующие изменения %Ora_Home%\wlserver\server\lib\consoleapp\webapp\WEB-INF\web.xml.
  Меняем строку

How does Varonis monitor Kerberos?

Varonis monitors Active Directory domains for Kerberos attacks, privilege escalations, brute force attacks, and more. Our security analytics combines user events, security events, and perimeter telemetry – to detect and alert on potential attacks and security vulnerabilities.

Sample Varonis threat models that help detect Kerberos attacks include:

• Potential pass-the-ticket attack: access to a resource was requested without proper authentication, bypassing the Kerberos protocol.
• Failed privilege escalation detected via vulnerability in Kerberos: an attacker tried to elevate their privileges via Kerberos vulnerability.
• Potential brute-force attack targeting a specific account: an unusual amount of authentication failures from a single IP address by a single user has occurred.
• Security certificate activity by non-administrators: Activity was detected on certification files by a user who is not an administrator – potentially indicating an attacker trying to steal signatures.
• …and that’s just the beginning!

Discover how Varonis detects Kerberos attacks for real with a 1:1 demo today – and get in touch to learn out more about our threat models.

What is the difference between Kerberos and NTLM?

Before Kerberos, Microsoft used an authentication technology called NTLM. NTLM stands for NT Lan Manager and is a challenge-response authentication protocol. The target computer or domain controller challenge and check the password, and store password hashes for continued use.

The biggest difference between the two systems is the third-party verification and stronger encryption capability in Kerberos. This extra step in the process provides a significant additional layer of security over NTLM.

NTLM systems can get hacked in a matter of hours these days: it’s simply older technology, and you shouldn’t rely upon NTLM to protect sensitive data.

Нюансы работы[править]

Увеличиваем срок выдаваемого билетаправить

Тикет Kerberos по умолчанию выдаётся не более чем на 1 сутки. Если хотите выдавать тикет больше, чем на сутки, пропишите:

1. max_life = 30d
   

   в файле /var/lib/kerberos/krb5kdc/kdc.conf (максимальный срок выдаваемого тикета — 30 дней)

2. на LDAP-сервере dn: krbPrincipalName=krbtgt/<ваш_домен>

   krbMaxTicketLife: 2592000
   

   (срок выдаваемого тикета с сервера — 30 дней, указывается в количестве секунд)

3. Для указания периода возобновления тикета (хотя странно, имея такой «длинный» тикет, указывать период его обновления) параметры

   max_renewable_life = 30d
   

   и krbMaxRenewableAge: 2592000 соответственно.

Использование старых версий Kerberos с новымиправить

В новых версиях Kerberos слабые алгоритмы (например, des-cbc-crc:afs3) по умолчанию запрещены к использованию. А на старых системах (клиентах или серверах на Пятой или Шестой платформе) они используются. Чтобы включить их поддержку, на новой системе пропишите в раздел файла /etc/krb5.conf строку

allow_weak_crypto = true

Без этого с билетами Kerberos (и, как следствие с монтированием каталогов и доступом к прокси-серверу) будут проблемы.

Ошибка запуска службы krb5kdcправить

Если в журнале при запуске службы krb5kdc появляется ошибка:

preauth pkinit failed to initialize: No realms configured correctly for pkinit support

то это означает, что сервер LDAP (slapd) ещё не успел проинициализироваться для доступа krb5kdc. Увеличьте уровень загрузки службы krb5kdc с 40 до 41 (между запуском этих служб появится служба anacron):

# subst 's/chkconfig:   345 40 /chkconfig:   345 41 /' /etc/init.d/krb5kdc
# chkconfig krb5kdc on

Исправлено в krb5-kdc  с версии 1.11.2-alt3 

Introduction

This article explains how to configure an Arch Linux system to participate in an Active Directory domain. This article was written and tested on a fresh installation, and it is assumed that all configuration files are in their unmodified, post-installation state. For the duration of the article, the example Active Directory domain will use the following configuration:

• NetBIOS domain name: INTERNAL
• DNS domain name: internal.domain.tld
• Kerberos realm: INTERNAL.DOMAIN.TLD
• First DC: server1.internal.domain.tld with IP address 192.168.1.1
• Second DC: server2.internal.domain.tld with IP address 192.168.1.2

In most small networks, the DCs (domain controllers) also hold the DNS server role. This may not be true in larger networks. Generally, DCs also hold the NTP role, but not always. Consult your network administrator to verify correct values for DNS and NTP servers.

Настройка squid для авторизации на основе членства в доменной группе LDAP

Приступаем к финальному шагу. Для реализации авторизации на основе членства в доменной группе в squid используется внешний acl, т.н. параметр external_acl_type. Общая схема работы примерно следующая:

# задаем external_acl_type для взаимодействия с LDAP
external_acl_type произвольное_имя_ext_acl %LOGIN /путь/к/хелперу/squid_ldap_group -R \
-b "BaseDN" -f "фильтр с переменной %v и %a" -D пользователь_ad@домен -K -W /файл/с/паролем имя_dc
# где переменная %v подставляется за счет указания значения %LOGIN,
#  которое извлекает имя аутентифицированного пользователя
# далее необходимо задать acl, которое будет передавать в переменную %a имя групп
acl имя_acl external произволное_имя_ext_acl передаваемое_название_группы
# далее необходимо с образовавшимся acl работать как с обычным acl,
# то есть задавать какие-то разрешения с помощью соответствующих параметров

Если данную схему наложить на наш домен и нашу задачу, то получится примерно следующий конфиг:

ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth
auth_param negotiate children 15
auth_param negotiate keep_alive on
external_acl_type ldap_verify %LOGIN /usr/lib/squid3/squid_ldap_group -R \
-b "dc=ad,dc=local" -f  "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))"\
-D adsquid@ad.local -K -W /etc/squid3/aduser dc.ad.local.
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
acl localnet src 10.0.0.0/16
acl to_localnet dst 10.0.0.0/16
acl users external ldap_verify squid
acl users-list external ldap_verify squid-list
acl whitelist dstdomain "/etc/squid3/acls/whitelist.acl"
acl allusers proxy_auth REQUIRED
http_access allow manager localhost
http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow users
http_access allow users-list whitelist
http_access deny !allusers all
http_access deny all
http_port 10.0.0.10:3129
http_port 127.0.0.1:3129
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

Давайте разберем получившийся конфиг. Как видно, добавился параметр external_acl_type, заставляющий sqiud обращаться к каталогу LDAP, расположенному на контроллере домена dc.ad.local, через хелпер squid_ldap_group. squid_ldap_group  ищет пользователей в каталоге, начиная с пути  dc=ad,dc=local, авторизованных пользователей, принадлежащих некоторым группам, имена которых (групп) передаются из acl в переменную %a. Как мы видим, у нас пропал параметр -d за ненадобностью и появился параметр -K. Давайте его разберем. Мы , что при Negotiate Kerberos аутентификации имя пользователя у нас получается в виде пользователь@ДОМЕН, а хелпер  squid_ldap_group использует имена в формате пользователь (то есть без доменной части). Так вот, ключ -K заставляет  squid_ldap_group «обрезать» часть имени @ДОМЕН и корректно сравнивать имя пользователя и группу.

Далее мы видим, что появилось 3 новых  acl — users, users-list и whitelist, которые проверяют принадлежность пользователя к группе с именем squid, к группе с именем squid-list и задает белый список сайтов соответственно. При этом, про первые 2 acl было бы понятней сказать, что они передают в  external_acl_type с именем  ldap_verify  имя группы, которой должен принадлежать аутентифицированный пользователь.

Ну и последнее — это появление двух параметров http_access, которые разрешают доступ acl с именем users и acl с именем users-list при доступе этих пользователей к сайтам из acl whitelist. Кроме того, был убран параметр  http_access allow allusers, который разрешал доступ всем аутентифицированным пользователям.

На этом в настройке можно поставить точку. Перезапускаем сквид и наши пользователи, которые входят в доменные группы squid и squid-list могут работать в интернете.

DNSAdmins

Microsoft не только реализовала собственный DNS-сервер, но и внедрила для него протокол управления, позволяющий интегрировать DNS-сервер с доменами Active Directory. По умолчанию контроллеры домена также являются DNS-серверами, поэтому DNS-серверы должны быть доступны каждому пользователю домена. Это, в свою очередь, открывает потенциальную возможность для атаки на контроллеры домена: с одной стороны мы имеем сам протокол DNS, а с другой — протокол управления, основанный на RPC.

Пользователь, входящий в группу DNSAdmins или имеющий права на запись в объекты DNS-сервера, может загрузить на DNS-сервер произвольную DLL с привилегиями System. Это очень опасно, поскольку многие корпоративные сети используют контроллер домена в качестве DNS-сервера.

Таким образом, для реализации атаки мы можем просто загрузить на DNS-сервер произвольную библиотеку с помощью dnscmd (путь должен быть доступен для чтения DC):

Чтобы проверить, была ли загружена DLL, можно использовать следующую команду:

Так как наш пользователь — член группы DNSAdmins, мы можем перезапустить службу DNS:

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

Пример PowerShell-кода в DLL

После успешного выполнения скрипта мы будем прослушивать на своем хосте обратное подключение:

Пример успешного бэкконнекта

В результате мы получим права на DC.

Настройка Kerberos 5

Настройка клиента Kerberos 5 выполняется гораздо проще, чем настройка сервера. Как минимум, вы должны установить пакеты клиента и сформировать для своих клиентов правильный файл конфигурации krb5.conf. Версии rsh и rlogin, поддерживающие Kerberos, также потребуют некоторых изменений в конфигурации.

1.Убедитесь в том, что между клиентом Kerberos и KDC время синхронизировано. За дополнительной информаций обратитесь к разделу Настройка сервера Kerberos 5. Помимо этого, до установки на компьютере клиентских программ Kerberos необходимо убедиться в корректной работе DNS.

2.Установите пакеты krb5-libs и krb5-workstation на всех клиентских компьютерах вашей сферы. Вы должны поместить собственную версию файла /etc/krb5.conf на клиентские компьютеры; обычно это тот же файл krb5.conf, что и на KDC.

3.До того как определённая рабочая станция в вашей сфере позволит пользователям подключиться, используя rsh и rlogin, использующие Kerberos, на этом компьютере необходимо установить пакет xinetd, и создать для него собственную запись узла в базе данных Kerberos. Серверным программам kshd и klogind также понадобится получить ключи своих учётных записей служб.

Воспользовавшись kadmin добавьте учётную запись компьютера для этой рабочей станции. Именем экземпляра в этом случае будет имя рабочей станции. Так как вам никогда больше не понадобится вводить пароль для этой учётной записи, и вероятно, вы не будет против сильного пароля, воспользуйтесь параметром -randkey команды addprinc для программы kadmin для создания учётной записи и присвоения ей случайного пароля:

addprinc -randkey host/blah.example.com

Обратите внимание, после создания учётной записи, вы можете извлечь ключи рабочей станции, выполнив команду kadmin на самой рабочей станции и воспользовавшись командой ktadd в kadmin:

ktadd -k /etc/krb5.keytab host/blah.example.com

Чтобы использовать версии rsh и rlogin, поддерживающие Kerberos, вы должны включить klogin, eklogin и kshell.

4.Также может понадобиться запуск других сетевых служб, поддерживающих Kerberos. Чтобы использовать telnet с поддержкой Kerberos, вы должны включить krb5-telnet.
Чтобы предоставить FTP доступ, создайте и извлеките ключ для учётной записи корня ftp, указав в качестве экземпляра имя FTP сервера. Затем включите gssftp.
Сервер IMAP, включенный в пакет imap, будет использовать проверку подлинности GSS-API с Kerberos 5, если найдёт соответствующий ключ в /etc/krb5.keytab. Корнем для учётной записи должен быть imap. Служба CVS gserver использует учётную запись с корнем cvs и во остальном совпадает с ??????????????? pserver.

Отладка и устранение проблем c Kerberos аутентификацией в Apache

При возникновении проблем, включите режим отладки в apache2:

В файле /etc/apache2/sites-available/000-defaults.conf перед закрывающим тегом </VirtualHost> впишите:

LogLevel trace8

Перезагрузите apach, теперь в error.log апача вы сможете видеть какие ошибки выдаёт модуль Kerberos.

Для удобства используйте команду с фильтром по IP

Для работы и диагностики с Kerberos можно использовать команды kinit и klist.

kinit – утилита для получения и кеширования Kerberos тикетов. Пример:

При правильно сгенерированом keytab файле, команда успешно выполниться, и вы получите сообщение об успешной аутентификации

Утилитой klist можно посмотреть кэшированные тикеты Kerberos:

Functions

This function provides a simple way to verify that a user name and password
match those normally used for Kerberos authentication.
It does this by checking that the supplied user name and password can be
used to get a ticket for the supplied service.
If the user name does not contain a realm, then the default realm supplied
is used.

For this to work properly the Kerberos must be configured properly on this
machine.
That will likely mean ensuring that the edu.mit.Kerberos preference file
has the correct realms and KDCs listed.

IMPORTANT: This method is vulnerable to KDC spoofing attacks and it should
only be used for testing. Do not use this in any production system — your
security could be compromised if you do.

This function returns the service principal for the server given a service type and hostname.

Details are looked up via the file.

Initializes a context for client-side authentication with the given service principal.

Initializes a context for server-side authentication with the given service principal.

Развитие протокола

Ранние версии

Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.

Kerberos 4

Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, Andrew File System) использовали идеи Kerberos 4 для своих систем аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller) и Клиффорд Ньюман (Clifford Neuman).

Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина», а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT.

Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт.

Позже Эррол Янг (Errol Young) в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones») и могла свободно распространяться за пределами США.

В 2006 году было объявлено о прекращении поддержки Kerberos 4.

Kerberos 5

На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.

Использование и распространение

Распространение реализации Kerberos происходит в рамках авторского права, аналогичного правам для BSD.

В настоящее время множество ОС поддерживает данный протокол, в число которых входят:

• различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США (англ.).