Kerberos — один из тех протоколов, которые в инфраструктуре работают «тихо». Пользователь вошёл в систему один раз, и дальше всё открывается без лишних вопросов. За этим удобством стоит строгая модель доверия, построенная вокруг KDC и тикетов.
Но есть нюанс: классический Kerberos — это по сути однофакторная аутентификация. Если пароль скомпрометирован, вся цепочка доверия находится под угрозой.
В этой статье разберём, как можно усилить Kerberos с помощью второго фактора и как это реализовано в связке MULTIDIRECTORY и MULTIFACTOR.
Почему каталог и 2FA вообще должны работать вместе
Служба каталогов в корпоративной инфраструктуре — это не просто «база пользователей». Это точка, в которой сходится управление доступами, ролями, политиками и идентификацией.
Через неё проходят:
Входы в домен
Доступ к сервисам
Доверительные отношения между системами
Kerberos в этой связке отвечает за то, чтобы пользователь один раз доказал свою подлинность и в дальнейшем получал доступ к ресурсам без повторной проверки.
Проблема в том, что вся эта модель долгое время опиралась на пароль как основной фактор. При атаках это слабое место: утечки, фишинг, reuse паролей — всё это делает даже сильную инфраструктуру уязвимой.
Добавление второго фактора на уровне каталога и Kerberos позволяет закрыть этот разрыв.
Где в Kerberos появляется второй фактор
Если упростить, Kerberos-аутентификация выглядит так:
1) Пользователь вводит учётные данные.
2) Клиент обращается к службе, которая выдаёт билеты и управляет доверием в системе — KDC (AS-REQ).
3) KDC возвращает TGT (Ticket Granting Ticket, ключевой элемент аутентификации в Kerberos) и сессионный ключ, зашифрованные на ключе пользователя (AS-REP).
4) Клиент расшифровывает сессионный ключ, используя пароль пользователя.
5) Далее клиент использует сессионный ключ для запроса сервисных тикетов (TGS) и доступа к сервисам.
Ключевой этап — момент получения TGT. Именно здесь система решает: «доверяем пользователю или нет».
В классической схеме решение принимается на основании пароля. В расширенной — добавляется дополнительная проверка.
Фактически второй фактор встраивается в этап первичной аутентификации (AS-REQ / AS-REP). Это важно, потому что:
защита распространяется на всю Kerberos-модель
не требуется дорабатывать приложения
контроль остаётся централизованным
Как это реализовано в MULTIDIRECTORY
В российской службе каталогов MULTIDIRECTORY Kerberos — не внешний компонент, а часть системы. KDC работает как часть службы каталогов и напрямую участвует в проверке учётных данных. Интеграция с системой двухфакторной аутентификации MULTIFACTOR добавляет к этому процессу ещё один шаг.
Процесс аутентификации в итоге выглядит так:
Пользователь инициирует вход — например, на рабочую станцию или в сервис. Клиент отправляет запрос в KDC. Система не сразу выдаёт TGT, а инициирует проверку второго фактора через MULTIFACTOR.
Пользователь получает запрос на подтверждение по пуш-уведомлениям. После успешного подтверждения KDC завершает аутентификацию и выдаёт TGT.
Если второй фактор не пройден, процесс обрывается на этом этапе.
Что это даёт на практике
Главное изменение — перенос контроля безопасности на уровень инфраструктуры.
Раньше второй фактор чаще всего реализовывался на уровне отдельных систем: VPN, почта, SaaS-сервисы. В итоге защита получалась фрагментированной. В случае с Kerberos ситуация другая. Проверка происходит в момент выдачи TGT, а значит:
защищается сам доменный вход
автоматически защищаются все сервисы, использующие Kerberos
исчезает необходимость внедрять 2FA в каждом приложении отдельно
При этом для пользователя сценарий почти не меняется, добавляется только простое подтверждение входа.
Почему интеграция от одного вендора упрощает жизнь
Теоретически можно собрать такую схему из разных решений: отдельно каталог, отдельно 2FA, между ними прокси или кастомная интеграция. На практике это часто приводит к усложнению архитектуры. Когда оба компонента из одной экосистемы, это снимает ряд типичных проблем.
Во-первых, интеграция не требует дополнительных прослоек. Взаимодействие между KDC и сервисом второго фактора уже предусмотрено и поддерживается на уровне продукта.
Во-вторых, управление становится более предсказуемым. Пользователи, группы и политики находятся в каталоге, а методы аутентификации — в MULTIFACTOR, но логика их применения согласована.
В-третьих, снижается нагрузка на инфраструктуру. MULTIFACTOR работает по облачной модели и не требует разворачивания дополнительных серверов внутри периметра.
Наконец, остаётся гибкость: можно использовать разные методы второго фактора в зависимости от сценария — от OTP до пушей и биометрии.
Где это действительно нужно
Не в каждой инфраструктуре есть смысл сразу внедрять 2FA на уровне Kerberos, но есть сценарии, где это даёт максимальный эффект.
В первую очередь это корпоративные домены, где через Kerberos проходит доступ к большинству ресурсов. Усиление аутентификации здесь автоматически повышает безопасность всей системы.
Второй тип — удалённый доступ и VPN. В условиях распределённых команд защита только паролем уже давно не считается достаточной.
Отдельно стоит выделить критические системы и администраторские доступы. Здесь второй фактор — не столько дополнительная опция, сколько базовое требование.
Такие решения актуальны в гетерогенных средах и при миграции с Active Directory, когда важно сохранить привычную модель аутентификации, но при этом повысить её уровень безопасности.
Итог
Kerberos остаётся фундаментом аутентификации в корпоративных инфраструктурах, но требования к безопасности вокруг него изменились.
Добавление второго фактора на этапе выдачи TGT — это логичное развитие модели, которое позволяет усилить защиту без радикальных изменений в архитектуре.
Связка MULTIDIRECTORY и MULTIFACTOR реализует этот подход на практике: второй фактор встраивается прямо в Kerberos-поток, управление остаётся централизованным, а пользователи получают дополнительный уровень защиты без заметного усложнения сценариев. Если у вас уже есть Kerberos — это один из самых естественных способов сделать его заметно безопаснее.