Коротко. Сквозной Kerberos в RX работает только внутри домена, поэтому RX подключается к Keycloak по OpenID Connect, а Keycloak решает сам: есть билет Kerberos, вход сразу; нет билета, логин, пароль через LDAPS и код из приложения. Чаще всего ломается сопоставление имени в preferred_username с логином в RX.

Типовое пожелание к входу в систему звучит так: в офисе открыл браузер и сразу работаешь, без пароля; из дома или с телефона ввёл доменный логин и пароль, а потом код из приложения. Directum RX умеет и сквозной вход по Kerberos, и вход через внешнего поставщика, и второй фактор по сертификату. Но сквозной Kerberos работает только внутри домена, а встроенный второй фактор требует токен у каждого пользователя и включается для всех сразу. Разбираем схему, которая разделяет вход внутри и снаружи, и места, где она обычно ломается. Это описание схемы, а не готовая конфигурация: детали зависят от вашей службы каталогов и сети.

Симптом

Вход настроен одним из двух способов, и оба не устраивают.

  • Сквозной Kerberos. В офисе всё прекрасно. Снаружи браузер показывает системное окно ввода логина и пароля, которое пользователи не понимают, пароль уходит в систему напрямую, второго фактора нет.
  • Логин и пароль везде. Внутри сети сотрудники вводят пароль по десять раз в день и начинают сохранять его в браузере. Снаружи по-прежнему только пароль.

Служба безопасности просит второй фактор для доступа из интернета, пользователи просят не трогать вход в офисе.

Почему так

В RX на Linux внешняя аутентификация настраивается одним параметром EXTERNAL_AUTHENTICATION_TYPE в config.yml. Значение Kerberos включает сквозной вход по доменному билету, и по документации вендора он работает только внутри домена. Значение OpenIdConnect передаёт вход внешнему поставщику. Вендор называет OpenID Connect рекомендуемым протоколом и приводит пример настройки с Keycloak.

Отсюда схема: RX доверяет поставщику входа по OpenID Connect, а уже поставщик решает, как проверять пользователя. Внутри сети по билету Kerberos, снаружи формой логина и пароля с одноразовым кодом.

                    ┌──────────────────── Keycloak ────────────────────┐
браузер ──► RX ──►  │ билет Kerberos есть?  да ──► вход без вопросов    │ ──► RX: вход выполнен
 (OIDC)             │                       нет ─► логин и пароль       │
                    │                              (проверка в AD по    │
                    │                               LDAPS) + код TOTP   │
                    └──────────────────────────────────────────────────┘

Встроенный второй фактор или код из приложения

В RX есть своя двухфакторная аутентификация при входе в веб-клиент. После пароля или внешнего поставщика пользователь подтверждает вход сертификатом: токен с закрытым ключом, ПИН-код, подпись через веб-агент. Поддерживаются сертификаты RSA и ГОСТ, в том числе тот, которым сотрудник уже подписывает документы. Включается параметром MFA_ENABLED для всей системы.

Сертификат на токене (встроено в RX) Код из приложения (через Keycloak)
Что нужно пользователю токен, веб-агент, для ГОСТ средство криптозащиты телефон с приложением-аутентификатором
Внутри сети тоже спрашивается не спрашивается, вход по билету Kerberos
Сервис интеграции, мобильные приложения не поддерживается: вход либо запрещается, либо второй фактор пропускается решается на стороне поставщика
Когда выбирать токены уже выданы для подписания, второй фактор нужен всем второй фактор нужен только снаружи, токенов нет

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

Из чего собирается

Связь с каталогом. В Keycloak подключается служба каталогов (Active Directory, ALD Pro, Samba) как источник пользователей по LDAP. Только по LDAPS, на порт 636, с сертификатом контроллера домена, которому Keycloak доверяет: по обычному LDAP пароль пользователя идёт по сети открытым текстом. Пароли Keycloak не хранит, он проверяет их в каталоге.

Kerberos. В той же связи с каталогом включается проверка Kerberos. Для Keycloak заводится служебная учётная запись с именем SPN HTTP/<имя сервера Keycloak>@<ОБЛАСТЬ> и выгружается keytab. Браузеры на рабочих местах должны считать адрес Keycloak доверенным для Kerberos: в Chrome и Edge это политика AuthServerAllowlist, в Firefox параметр network.negotiate-auth.trusted-uris. Без этого браузер билет не предъявит и пользователь увидит форму.

Порядок входа. В сценарии входа через браузер Kerberos ставится альтернативой форме. Есть билет, вход проходит сразу. Нет билета, например снаружи, открывается форма логина и пароля, после неё обязательный шаг с одноразовым кодом. Код генерирует приложение-аутентификатор на телефоне. При первом входе снаружи Keycloak сам предлагает пользователю привязать приложение.

RX. В конфигураторе Directum Launcher в общих настройках задаются EXTERNAL_AUTHENTICATION_TYPE: 'OpenIdConnect', идентификатор и секрет клиента, адрес метаданных поставщика и утверждение, в котором приходит имя учётной записи. Для Keycloak это preferred_username. Полный список параметров и шаги на стороне Keycloak есть в справке RX, статья «Настройка OpenID Connect 1.0 с использованием Keycloak».

Сам Keycloak ставится за тот же обратный прокси, что и RX, и для доступа снаружи публикуется только страница входа. Консоль администрирования Keycloak снаружи закрывается.

Где ломается

Что видят Причина Что проверить
В офисе вместо входа без пароля форма браузер не предъявляет билет адрес Keycloak в списке доверенных для Kerberos, рабочее место в домене
Ошибка Kerberos в журнале Keycloak SPN или keytab не того сервера, расхождение времени имя в SPN совпадает с адресом, по которому ходит браузер; время синхронизировано
Вход в Keycloak прошёл, RX говорит «пользователь не найден» имя в утверждении не совпадает с логином в RX что приходит в preferred_username и в каком виде логины хранятся в справочнике учётных записей RX
Учётки в домене блокируются лишние попытки проверки пароля порог блокировки в домене с запасом: по документации RX при входе бывает до четырёх попыток подключения
Не подключается к каталогу нет доверия к сертификату контроллера корневой сертификат домена в хранилище доверенных у Keycloak

Третья строка случается чаще всех. Keycloak приводит имена пользователей к нижнему регистру, а логины в RX могут быть записаны как Domain\Login или Login@REALM. Сопоставление настраивается сопоставителем утверждений в Keycloak так, чтобы в preferred_username приходило ровно то, что записано в RX.

Расхождение времени больше пяти минут ломает Kerberos целиком, разбор есть в справочнике ошибок.

Что сделать

  1. Определить, по какому признаку вход считается внутренним. В этой схеме признак один: есть ли у браузера доменный билет. Отдельно разрешать вход по адресу сети не нужно.
  2. Подключить каталог к Keycloak только по LDAPS.
  3. Завести SPN и keytab для Keycloak, раздать политику доверенных адресов браузерам через групповые политики.
  4. Настроить сценарий входа: Kerberos альтернативой, форма с обязательным одноразовым кодом.
  5. Подключить RX по OpenID Connect и проверить сопоставление имён на нескольких учётках с разным написанием.
  6. Проверить вход с рабочего места в домене, с личного ноутбука в офисной сети и снаружи.
  7. Поставить наблюдение за сроком сертификатов Keycloak и контроллера домена: истёкший сертификат останавливает вход у всех сразу.

Чего не делать

  • Не подключать каталог по LDAP без TLS. Пароли пойдут по сети открытым текстом.
  • Не публиковать консоль администрирования Keycloak наружу.
  • Не делать второй фактор через SMS для внутренних систем. SMS перехватывают и подменяют SIM-карту; приложение-аутентификатор надёжнее и бесплатно.
  • Не настраивать вход по образцу конфигурации другого заказчика. Имена, области и сопоставления у каждого свои.