Дополнительные настройки Kerberos-аутентификации

Настройка соответствия имен доменов и Realm. Конфигурационный файл realm-rules-config.xml

При прозрачной аутентификации приложение пытается найти пользователя в своей базе данных по атрибуту "Логин".

Расширить набор правил поиска логина во внутренней базе данных можно с помощью определения соответствия между доменом пользователя и внутренним наименованием домена.

Внутреннее наименование домена — это часть атрибута "Логин" класса "Сотрудник" (employee), представляющая домен. В зависимости от настроек синхронизации пользователей системы и Active Directory, логины сотрудников могут иметь вид login@domain, login и прочие.

В файле realm-rules-config.xml представлен набор правил, каждое из которых указывает соответствие между определенным наименованием домена внутри приложения и областью аутентификации (realm).

Например, по каким-то причинам логины из домена MSK.EXAMPLE.COM в системе заведены как @example и @example.com, такие логины не могут быть найдены по встроенным правилам поиска. Для расширения правил поиска конфигурационный файл realm-rules-config.xml должен иметь следующий вид:

<?xml version="1.0" encoding="UTF-8"?>
<realm-rules xmlns="http://naumen.ru/xmlschema/core/realm-rules-config/">
   <realm-accordance-rule internal-domain="example.com" realm="MSK.EXAMPLE.COM" />  
   <realm-accordance-rule internal-domain="example" realm="MSK.EXAMPLE.COM" />
</realm-rules>

В свойстве internal-domain определяется внутреннее наименование домена, в realm — имя области аутентификации пользователя.

После указанной настройки поиск логина user@msk.example.com будет дополнительно осуществлен по:

  • "user@example.com"
  • "user@example"
  • "example.com\user"
  • "example\user"

Файл realm-rules-config.xml должен находиться в каталоге, указанном в java-опции -Dext.prop.dir при запуске приложения.

Стандартный путь до конфигурационного файла realm-rules-config.xml следующий [каталог приложения]/conf/realm-rules-config.xml.

В общем случае наличие файла realm-rules-config.xml не обязательно.

Отладка ошибок аутентификации

Дополнительное логирование на сервере приложения

Для подробного вывода процесса аутентификации в лог приложения (logs/sdng.log) в файле log4j.properties установите параметры логирования, см. Проверка работы Kerberos-аутентификации.

Для вывода дополнительных сообщений в tomcat/logs/catalina.out добавьте в java-опции сервиса Tomcat следующую опцию:

-Dsun.security.krb5.debug=true

Логирование ошибок на стороне клиента

В некоторых случаях помогает включение записи ошибок Kerberos на клиентской машине, для этого установите ключ реестра через regedit.exe:

Путь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Ключ: LogLevel
Тип: REG_DWORD
Значение: 1

После перезапуска рабочей станции ошибки kerberos будут отображаться в журнале событий Windows (eventvwr.msc) в разделе System.

Команда setspn

Команда setspn используется для управления SPN записями в домене:

  • Добавление SPN к учетной записи:

    setspn -A SPN user@domain

  • Удаление SPN:

    setspn -D SPN user@domain

  • Список SPN, привязанных к пользователю:

    setspn -L user@domain

  • Поиск пользователей, к которым привязан указанный SPN:

    setspn -Q SPN

  • Поиск дублей SPN (может работать медленно):

    setspn -x

Подробнее о команде setspn можно прочитать в официальной документации Microsoft.

Применение новой конфигурации из krb5.conf (krb5.ini) без перезапуска приложения

Если krb5.conf (krb5.ini) был изменен, новые настройки могут быть применены в приложении после запуска консольного groovy-скрипта:

sun.security.krb5.Config.getInstance().refresh()

Просмотр содержимого keytab-файла

Существует несколько способов просмотреть список ключей в keytab-файле:

  • Утилита klist

    • ОС Linux. Используется утилита klist:

      klist -K -e -t -k ./naumen.keytab

      В Ubuntu Server утилита klist является частью пакета krb5-user. В CentOS/RHEL необходимо установить пакет krb5-workstation.

      После запуска утилиты будут выведены все содержащиеся ключи с типом шифрования, realm и SPN, для которого создавался ключ.

    • ОС Windows. Используется утилита klist.exe из поставки JDK для Windows:

      C:\naumen\java\bin\klist.exe -K -e -t -k ./naumen.keytab

  • Любой текстовый редактор. Keytab-файл является бинарным, но в нем можно найти SPN и realm открытым текстом.

Изменение типа шифрования для keytab-файла

По умолчанию ключи в keytab-файле шифруются с помощью шифрования rc4-hmac.

Чтобы изменить тип шифрования, выполните следующие действия:

  1. Установите свойство для служебной учетной записи в Active Directory:

    • "Данная учетная запись поддерживает 128-разрядное шифрование";
    • "Данная учетная запись поддерживает 256-разрядное шифрование".

  2. Сгенерируйте новый keytab-файл с ключом нужного шифрования.

    Для этого в команду ktpass передайте опцию "/crypto AES128-SHA1" или "/crypto AES256-SHA1", см. Создание SPN и keytab-файла.

    Если в профиле пользователя AD включены два типа шифрования, то в команду ktpass нужно передать "/crypto ALL".

  3. Скопируйте обновленный keytab-файл на сервер приложения. Путь до файла указан в конфигурационном файле dbaccess.properties (параметр "ru.naumen.core.authentication.spnego-authenticator.keytab").

Настройка прозрачной аутентификации при доступе в приложение по разным ссылкам

Чтобы пользователи могли входить в приложение по ссылкам https://support.msk.example.com и https://sc.msk.example.com, выполните следующие действия:

  • Если имена support.msk.example.com и sc.msk.example.com являются записями типа CNAME, то для работы прозрачной аутентификации дополнительной настройки не требуется.

  • Если имена support.msk.example.com и sc.msk.example.com являются записями типа A, то создайте дополнительные SPN, соответствующие DNS-именам при помощи команды setspn:

    setspn -A HTTP/support.msk.example.com naumen-spnego@msk.example.com
setspn -A HTTP/sc.msk.example.com naumen-spnego@msk.example.com

Изменение ссылки на приложение

Для смены ссылки на приложение добавьте новую CNAME на запись, на которую выписан SPN.

Для новой ссылки добавьте дополнительный SPN:

setspn -A HTTP/sc.msk.example.com msk.example.com\naumen-spnego

Если изменяется A-запись DNS, на которую выписан SPN, то для сохранения работы прозрачной аутентификации необходимо выполнить ряд действий. В примере рассматривается смена адреса приложения с "support.msk.example.com" на "sc.msk.example.com" (A-записи DNS).

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

  1. Откройте список всех SPN:

    setspn -L msk.example.com\naumen-spnego

  2. Удалите все существующие SPN:

    setspn -D HTTP/support.msk.example.com msk.example.com\naumen-spnego

    (в примере SPN один)

  3. Создайте новый keytab-файл:

    ktpass -princ HTTP/sc.msk.example.com@MSK.EXAMPLE.COM -mapuser naumen-spnego@msk.example.com -pass myP@ssw0rd -SetPass -out c:\TEMP\naumen.keytab

  4. Безопасно скопируйте новый keytab-файл на сервер приложения вместо старого. Путь до файла указан в конфигурационном файле dbaccess.properties (параметр "ru.naumen.core.authentication.spnego-authenticator.keytab").

    Если имя keytab-файла не изменилось, перезапуск приложения не требуется.