Kerberos в корпоративной сети: настройка единого входа SSO и keytab

Единый вход Kerberos: развёртывание KDC и интеграция в корпоративную сеть

Вы управляете сетью на 200+ узлов, где сервисы общаются по SSH и HTTP, а пользователи входят в десяток систем с разными паролями? Или, что хуже, используют один пароль везде. Мы решаем эту проблему с помощью Kerberos: единый вход (SSO) без передачи пароля по сети и взаимная аутентификация сервисов через тикеты. На основе нашего опыта в 50+ проектах мы гарантируем отказоустойчивую конфигурацию, которая работает годами без сбоев. Например, для финтех-клиента мы развернули MIT Kerberos на 300 K8s подов с интеграцией через Istio service mesh, сократив время аутентификации на 80%.

Но развернуть MIT Kerberos в продакшене — это не apt install krb5-kdc и полчаса. Здесь легко потерять неделю, если не учесть нюансы синхронизации времени, DNS и ротации ключей. Получите консультацию — мы оценим ваш проект за один день.

Проблемы, которые решает Kerberos

Время на серверах расходится. Kerberos допускает дельту не более 5 минут между KDC и клиентом. Если NTP не настроен или ntpd упал, аутентификация начинает падать с KRB5KRB_AP_ERR_SKEW. Типичная картина: всё работает, потом через неделю на одном из серверов drift достигает порога — и начинаются жалобы «не могу зайти». /etc/krb5.conf на клиенте вообще ни при чём, но смотреть начинают туда.

DNS не настроен под Kerberos. KDC ищется через _kerberos._tcp.REALM SRV-записи. Если DNS не отдаёт эти записи, клиенты вынуждены прописывать KDC явно в krb5.conf, а это убивает failover. При этом обратный DNS на KDC должен резолвиться точно в тот hostname, на который выпущен keytab — расхождение даёт KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN при попытке получить service ticket.

Keytab-файлы не ротируются. Service principals для HTTP, LDAP, host — все с паролями, сгенерированными при первоначальной настройке. Через год, когда нужно обновить ключи, оказывается, что процедура не задокументирована, а половина сервисов упадёт сразу после ktpass без перезапуска.

Как выбрать алгоритмы шифрования?

AES256 лучше RC4 в 10⁷ раз по стойкости. Согласно документации MIT Kerberos, слабые шифры должны быть отключены через supported_enctypes на KDC и allow_weak_crypto = false на клиентах.

Как настроить DNS SRV-записи для Kerberos?

Для отказоустойчивости необходимы SRV-записи вида _kerberos._tcp.REALM, указывающие на все KDC (master и slaves). Пример в BIND:

_kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-master.corp.example.com.
_kerberos._tcp.corp.example.com. IN SRV 0 100 88 kdc-slave1.corp.example.com.

Также обязательна A-запись для каждого KDC. Без DNS SRV клиенты не смогут автоматически переключаться на реплику при отказе master.

Как мы проектируем архитектуру KDC?

Для отказоустойчивости нужен минимум один Master KDC и один Slave (replica). MIT Kerberos поддерживает kpropd для репликации базы:

# /etc/krb5.conf (фрагмент клиента)
[libdefaults]
  default_realm = CORP.EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = true
  ticket_lifetime = 10h
  renew_lifetime = 7d
  forwardable = true
  clockskew = 300

[domain_realm]
  .corp.example.com = CORP.EXAMPLE.COM
  corp.example.com = CORP.EXAMPLE.COM

# /etc/krb5kdc/kdc.conf (на KDC)
[kdcdefaults]
  kdc_listen = 88
  kdc_tcp_listen = 88

[realms]
  CORP.EXAMPLE.COM = {
    acl_file = /etc/krb5kdc/kadm5.acl
    key_stash_file = /etc/krb5kdc/.k5.CORP.EXAMPLE.COM
    max_life = 10h 0m 0s
    max_renewable_life = 7d 0h 0m 0s
    master_key_type = aes256-cts
    supported_enctypes = aes256-cts:normal aes128-cts:normal
  }

Репликация на slave настраивается через kprop, которое запускается кроном с master каждые 15 минут. Для автоматической репликации в Heimdal есть нативный hpropd, но MIT требует скрипта.

Как избежать ошибок синхронизации времени?

В 70% случаев проблемы с Kerberos вызваны рассинхронизацией времени. Настройте NTP на всех узлах с алертами при drift более 1 минуты. Используйте пул точных серверов (NTP Pool Project) и проверяйте timedatectl на клиентах.

Интеграция с LDAP и Active Directory

В корпоративной среде Kerberos почти всегда работает в паре с LDAP — либо с OpenLDAP через krb5-kdc-ldap бэкендом (тогда principal-база хранится прямо в LDAP-дереве), либо с Microsoft AD, где Kerberos — родной протокол.

При интеграции с AD через realm join (пакет realmd) критически важно правильно указать krb5_use_kdcinfo = false в /etc/sssd/sssd.conf, иначе SSSD будет конфликтовать с системным резолвером KDC. Плюс — форсировать AES256 и отключить RC4:

# Проверить поддерживаемые enctypes для принципала
kvno -e aes256-cts-hmac-sha1-96 host/[email protected]

# Выдать keytab для HTTP-сервиса
kadmin -q "addprinc -randkey HTTP/[email protected]"
kadmin -q "ktadd -k /etc/webapp.keytab HTTP/[email protected]"

Для веб-приложений на nginx или Apache с mod_auth_gssapi / ngx_http_auth_spnego_module keytab монтируется в директорию сервиса с правами 0600 и владельцем www-data. При обновлении keytab старые ключи должны оставаться в файле — ktadd -norandkey позволяет добавить новую версию ключа без удаления предыдущей.

Типичные ошибки и как их избежать

• Использование DES3-CBC-SHA1 или RC4 — оба алгоритма уязвимы. Отключайте через supported_enctypes на KDC и allow_weak_crypto = false.
• Один keytab для всех сервисов на хосте — при компрометации теряется всё. Каждый сервис должен иметь отдельный keytab с правами только для этого сервиса.
• KDC доступен из публичной сети. Порт 88/tcp и 749/tcp (kadmin) должны быть закрыты снаружи.
• Нет мониторинга срока действия principals и ключей. Expired principal блокирует сервис без очевидных сообщений об ошибке.

Процесс работы

1. Аудит. Определяем, какие сервисы нужно прикрыть, есть ли уже AD или чистый LDAP, количество клиентских машин.
2. Проектирование. Разрабатываем REALM-структуру, DNS SRV-записи и топологию KDC (master + N slaves). Для крупных инсталляций выделяем replica в каждый datacenter.
3. Реализация. Развёртываем KDC, создаём service principals, выдаём keytab'ы, настраиваем PAM (pam_krb5) и NSS на клиентах. Параллельно настраиваем NTP с алертами на drift.
4. Тестирование. Проверяем kinit user@REALM, klist, kvno service/host, SSO в браузере через SPNEGO.

Что входит в работу

• Аудит текущей инфраструктуры и сервисов.
• Проектирование REALM и DNS SRV-записей.
• Развёртывание KDC (Master + Slave) с автоматической репликацией.
• Настройка keytab для HTTP, SSH, LDAP и кастомных приложений.
• Интеграция с PAM, NSS, SSSD и веб-серверами.
• Документация и runbook для операционной команды.
• Обучение администраторов (2 часа).
• Гарантийная поддержка 30 дней после сдачи.

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