Kerberos
Протокол в основном используется в локальных сетях. Широко применяется в Active Directory.
Основные понятия
Ticket- билет, зашифрованный пакетом данных, который выдается доверенным центром аутентификации.Key Distribution Center(KDC, центр распределения ключей, доверенный центр аутентификации) — третья доверенная сторона.Ticket Granting Ticket(TGT) — первичное удостоверение пользователя для доступа к сетевым ресурсам.Ticket Granting Service(TGS) — удостоверение для доступа к конкретному сетевому ресурсу, выдается на основе TGT.keytab(сокращение от «key table») — хранит долгосрочные ключи для одного или нескольких участников. Ключевые таблицы обычно представлены файлами в стандартном формате, хотя в редких случаях они могут быть представлены другими способами. Таблицы ключей чаще всего используются для того, чтобы серверные приложения могли принимать аутентификации от клиентов, но также могут использоваться для получения начальных учетных данных для клиентских приложений. См. документацию.ccache— кэш учетных данных. Хранит учетные данные Kerberos, пока они остаются действительными и, как правило, пока длится сеанс пользователя, так что многократная аутентификация в службе (например, подключение к веб-серверу или почтовому серверу более одного раза) не требует обращения в KDC каждый раз. См. документацию.
При любых взаимодействиях по сети не передаются ни пароли, ни значения хэша паролей в открытом виде. Kerberos требует, чтобы системные часы всех участников взаимодействия были синхронизированы.
Участники информационного обмена
Клиент— запрашивает доступ к сетевой службе.Сервер— узел, на котором работает сетевая служба.KDC— работает на физически защищенном сервере.
KDC ведет базу учетных данных с информацией обо всех участниках безопасности (security principal) своей области.
В базе данных KDC сохраняются криптографический ключ каждого участника безопасности, известный только этому участнику и службе KDC (долговременный ключ). На Клиенте и KDC должен храниться один и тот же долговременный ключ. На Сервере KDC - аналогично. Реализация этого механизма в спецификации протокола Kerberos не рассматривается.
Основные этапы работы
Приведено упрощённое описание схемы работы. Подробности следует смотреть в документации.
Аутентификация Клиента
- Если Клиент хочет получить доступ к Серверу, то он сначала должен обратиться к KDC.
- Клиент передает login, domain, зашифрованный долговременным ключом клиента timestamp.
- KDC находит в своей БД login, берет его долговременный пароль, расшифровывает полученный timestamp. Разница во времени отправки запроса и текущего времени на KDC не должна превышать установленного политикой Kerberos значения.
- KDC отправляет Клиенту TGT с установленным TTL, зашифрованный мастер-ключем KDC. Клиент не может его расшифровать, т.к. ключа KDC у него нет. Дополнительно KDC отправляет Клиенту информацию, включающую Сессионный ключ Клиент-KDC, необходимую для того, чтобы Клиент был уверен, что TGT пришел от доверенного KDC.
- KDC не выдаст TGT, если в запросе Клиента указаны неверные login, domain или использован неверный долговременный ключ Клиента.
Авторизация Клиента
- На этом этапе Клиент имеет выданный ему ранее TGT. Теперь ему нужно получить TGS для доступа к конкретному серверу.
- Клиент направляет KDC свой TGT и зашифрованный с помощью Сессионного ключа Клиент-KDC timestamp.
- KDC расшифровывает сообщение, проверяет TTL и информацию из TGT (login, domain).
- KDC создает отдельные TGS с установленными TTL для Сервера и для Клиента. Шифрует ключом Сервера. TGS Сервера включает Сессионный ключ Клиент-Сервер.
- Затем KDC шифрует всю эту информацию Сессионным ключом Клиент-KDC и возвращает Клиенту.
- Клиент, обладая Сессионным ключом Клиент-KDC, расшифровывает сообщение, получает себе TGS Клиента и TGS Сервера (Клиент не может его расшировать, т.к. он зашифрован ключом Сервера).
- Далее Клиент направляет Серверу зашифрованный timestamp и TGS Сервера. Сервер расшифровывает TGS Сервера своим ключом, достает из него Сессионный ключ Клиент-Сервер. Сервер удостоверяется в легитимности Клиента, т.к. Клиент мог получить зашифрованный TGS только от доверенного KDC.
- На этом этапе Клиент и Сервер имеют Сессионный ключ Клиент-Сервер и могут начать взаимодействовать.
Справочник CLI-утилит
См. документацию.
| Утилита | Что делает |
|---|---|
| kdestroy | Уничтожает активные авторизационные тикеты Kerberos пользователя, перезаписывая и удаляя кэш учетных данных, который их содержит. Если кэш учетных данных не указан, уничтожается кэш учетных данных по умолчанию. |
| kinit | Получает и кэширует первоначальный TGT для principal. |
| klist | Выводит список Kerberos pricnipal и Kerberos tickets, хранящиеся в кэше учетных данных, или ключи, хранящиеся в файле keytab. Например, klist -Aedf. |
kpasswd |
|
krb5-config |
|
ksu |
|
| kswitch | Делает указанный кэш учетных данных основным кэшем для коллекции, если коллекция кэша доступна. Например, kswitch -p <principal>. Проверять через klist. |
kvno |
|
sclient |
|
| ktadd | Добавляет principal в файл keytab. |
ktremove |
Удаляет запись из keytab. |
| ktutil | Вызывает командный интерфейс, с помощью которого администратор может читать, записывать или редактировать записи в keytab. |
Конфигурирование
Свойства Kerberos tickets
Для ticket можно задавать свойства, например, forwardable, см. описание свойств.
Конфигурационные файлы
krb5.conf— содержит информацию о конфигурации Kerberos, включая расположение KDC и серверов администрирования для интересующих областей Kerberos, значения по умолчанию для текущей области и для приложений Kerberos, а также сопоставления имен хостов с областями Kerberos. См. документацию.- Поддерживаемые форматы даты и времени , в т.ч. для указания значений в конфигурационных файлах.
Переменные окружения
См. документацию.
KRB5CCNAMEKRB5_KTNAMEKRB5_CONFIGKRB5_KDC_PROFILEKRB5RCACHENAMEKRB5RCACHETYPEKRB5RCACHEDIRKRB5_TRACE— можно использовать для отладки. Например:KRB5_CLIENT_KTNAMEKPROP_PORTGSS_MECH_CONFIG
Значения MIT Kerberos по умолчанию
См. документацию.
Раздел содержит в т.ч. пути по умолчанию для Unix-like систем.
Типы шифрования
См. документацию здесь и здесь.
В разделе перечислены поддерживаемые типы шифрования. Полезно убедиться, что ты используешь современный тип, не признанный weak или deprecated.