Подробный гайд по параметрам krb5.conf клиента Kerberos (MIT Kerberos / Heimdal)

Подробный гайд по настройке krb5.conf для Kerberos. Все параметры, секции, примеры конфигурации для Linux и Active Directory

2026.05.26                  

Подробный гайд по параметрам krb5.conf клиента Kerberos (MIT Kerberos / Heimdal)Подробный гайд по параметрам krb5.conf клиента Kerberos (MIT Kerberos / Heimdal) Файл /etc/krb5.conf (или /etc/krb5.conf.d/) — это главный конфигурационный файл клиента Kerberos (MIT Kerberos / Heimdal). Он управляет поведением библиотек libkrb5, включая поиск KDC, выбор алгоритмов шифрования, маппинг доменов в realms, логирование и интеграцию с приложениями.

Ниже приведён структурированный разбор всех основных секций и параметров с примерами и практическими рекомендациями.

Структура файла

krb5.conf использует INI-подобный синтаксис. Регистр важен в значениях, но не в именах секций. Файл читается сверху вниз, последние переопределения побеждают.

[секция]
параметр = значение

1. [libdefaults] — Глобальные настройки клиента

Параметр Описание Пример
default_realm Realm по умолчанию, если не указан в имени principal default_realm = EXAMPLE.COM
ticket_lifetime Время жизни TGT ticket_lifetime = 24h
renew_lifetime Максимальное время продления TGT renew_lifetime = 7d
forwardable Разрешить пересылку билетов (для SSH/KDE/etc) forwardable = true
proxiable Разрешить билеты proxiable = false
noaddresses Не включать IP-адреса в билеты (полезно при NAT/мобильности) noaddresses = true
clockskew Допустимое расхождение часов с KDC (по умолчанию 5 мин) clockskew = 300
dns_lookup_realm Искать realm через DNS SRV/TXT dns_lookup_realm = true
dns_lookup_kdc Искать KDC через DNS SRV dns_lookup_kdc = true
rdns Использовать обратный DNS для определения realm rdns = false
default_tgs_enctypes Алгоритмы для TGS-REQ default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tkt_enctypes Алгоритмы для AS-REQ default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes Разрешённые алгоритмы (переопределяет всё выше) permitted_enctypes = aes256-cts-hmac-sha1-96
disable_enterprise_principals Отключить поддержку enterprise principals (user@domain) disable_enterprise_principals = true
ignore_acceptor_hostname Игнорировать проверку hostname при получении service tickets ignore_acceptor_hostname = true

Рекомендация:

В современных системах оставляйте только AES-256/AES-128. Отключите des3-cbc-sha1 и rc4-hmac.

2. [realms] — Настройки по конкретным Realm

Каждый блок описывает один Kerberos-домен.

[realms]
EXAMPLE.COM = {
    kdc = kdc1.example.com
    kdc = kdc2.example.com
    admin_server = kdc1.example.com
    kpasswd_server = kdc1.example.com
    default_domain = example.com
    auth_to_local = RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//
    auth_to_local = DEFAULT
}
Параметр Описание
kdc Адрес KDC (можно несколько, клиент пробует по порядку)
admin_server Сервер kadmin/kadmind
kpasswd_server Сервер смены паролей
default_domain Домен по умолчанию для этого realm
auth_to_local Критично для Linux/Unix. Правила маппинга principal → локальный пользователь
v4_realm, v4_instance_convert Устаревшие параметры Kerberos v4 (игнорируйте)

Формат auth_to_local

auth_to_local = RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//
auth_to_local = DEFAULT
  • RULE:[1:$1@$0] → берёт первый компонент principal
  • (.*@EXAMPLE.COM) → применяет, если principal совпадает
  • s/@.*// → удаляет @REALM, оставляя только логин
  • DEFAULT → fallback: если principal user@REALM, то логин user

Для Active Directory часто используют:

auth_to_local = RULE:[1:$1@$0](.*@CORP.LOCAL)s/@.*//
auth_to_local = RULE:[2:$1@$0](.*@CORP.LOCAL)s/@.*//
auth_to_local = DEFAULT

3. [domain_realm] — Маппинг DNS-доменов в Kerberos Realm

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
host.dc.example.com = EXAMPLE.COM
  • Точка в начале (.example.com) применяется ко всем поддоменам.
  • Без точки — точное совпадение.
  • Используется, когда клиент не знает realm пользователя/KDC.

4. [logging] — Отладка и логирование

[logging]
default = FILE:/var/log/krb5lib.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

Формат:

ФАЙЛ:путь, SYSLOG[:уровень], CONSOLE, STDERR.

Уровни:

DEBUG, INFO, NOTICE, WARNING, ERROR, CRIT, ALERT, EMERG.

Пример для отладки:

[logging]
default = FILE:/var/log/krb5lib.log:DEBUG
kdc = SYSLOG:DEBUG

Внимание:

Включайте DEBUG только временно: логи содержат хеши/билеты в текстовом виде.

5. [appdefaults] — Настройки для конкретных приложений

[appdefaults]
pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 360000
    forwardable = true
    validate = false
}
sshd = {
    debug = false
    forwardable = true
}
gdm-password = {
    forwardable = true
}
  • pam: влияет на pam_krb5.so
  • sshd: настройки для GSSAPI-аутентификации SSH
  • kinit, kadmin, ftp, telnet и др.

6. [capaths] — Пути для cross-realm аутентификации

Если у вас несколько realm и они не доверяют друг другу напрямую, задаются транзитные realm.

[capaths]
EXAMPLE.COM = {
    OTHER.REALM = .
}
OTHER.REALM = {
    EXAMPLE.COM = .
}
  • . означает прямое доверие.
  • Если между realm нет прямого trust, KDC использует цепочку из capaths.
  • В современных AD-лесов доверия транзитивны, секция обычно не нужна.

7. Продвинутые/Редкие секции

Секция Назначение
[plugins] Подключение плагинов preauth, KDC, CCACHE
[dbmodules] Бэкенды для KDC (LDAP, SQL, PKCS#11)
[realms] -> kdc = { ... } Настройки балансировки/приоритетов KDC
spake_preauth_* Настройки SPAKE (современный preauth вместо пароля)
pkinit_* Настройки аутентификации по сертификатам

Пример [plugins]:

[plugins]
preauth = {
    module = pkinit:/usr/lib/krb5/plugins/preauth/pkinit.so
}

Полный рабочий пример

[libdefaults]
    default_realm = CORP.LOCAL
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    noaddresses = true
    dns_lookup_realm = false
    dns_lookup_kdc = false
    clockskew = 300
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

[realms]
    CORP.LOCAL = {
        kdc = dc1.corp.local
        kdc = dc2.corp.local
        admin_server = dc1.corp.local
        kpasswd_server = dc1.corp.local
        default_domain = corp.local
        auth_to_local = RULE:[1:$1@$0](.*@CORP.LOCAL)s/@.*//
        auth_to_local = DEFAULT
    }

[domain_realm]
    .corp.local = CORP.LOCAL
    corp.local = CORP.LOCAL

[logging]
    default = FILE:/var/log/krb5lib.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[appdefaults]
    pam = {
        debug = false
        ticket_lifetime = 36000
        renew_lifetime = 360000
        forwardable = true
    }

Валидация и отладка

1. Проверка синтаксиса:
   krb5-config --version
   klist -V
2. Получение TGT с отладкой:
   KRB5_TRACE=/dev/stdout kinit username@CORP.LOCAL
3. Проверка маппинга principal → пользователь:
   kinit username@CORP.LOCAL
   klist
   ssh -vvv user@host  # смотрите GSSAPI negotiation
4. Проверка DNS (если включено):
   dig SRV _kerberos._udp.CORP.LOCAL
   dig SRV _kerberos._tcp.CORP.LOCAL
   dig TXT CORP.LOCAL
5. Синхронизация времени (обязательно!):
   chronyc tracking
   ntpq -p
   timedatectl status

Рекомендации по безопасности

Параметр Рекомендация
permitted_enctypes Только aes256-cts-hmac-sha1-96 и aes128-cts-hmac-sha1-96
dns_lookup_* Отключайте в production, используйте явные kdc/realm
clockskew Не увеличивайте > 300 сек без необходимости
noaddresses true для ноутбуков/NAT, false для стационаров с жёсткой привязкой к IP
Логирование Не храните DEBUG логи дольше сессии отладки
Файл chmod 644 /etc/krb5.conf, владелец root:root

Полезные ссылки

  • man krb5.conf
  • MIT Kerberos Documentation: https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html
  • Инструменты: kinit -V, kvno, klist -e, KRB5_TRACE=/dev/stdout
  • Интеграция с SSSD/Realmd: man sssd-krb5, realm discover

Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.

×

Полный размер Слайдшоу Предыдущий Следующий