kerberos

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

Общие сведения о Kerberos-аутентификации и особенности реализации в SMP

Основные понятия и определения

• Kerberos — сетевой протокол аутентификации, позволяющий безопасно передавать данные через незащищённые сети для безопасной идентификации.

  Также Kerberos — набор бесплатного программного обеспечения от Массачусетского технологического института MIT (Massachusetts Institute of Technology), разработавшего этот протокол. Организация протокола направлена в первую очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Сообщения, отправляемые через протокол Kerberos, защищены от прослушивания и атак повторного воспроизведения.

• Realm — область (домен) аутентификации в инфраструктуре Kerberos. Значение чувствительно к регистру символов.
• SPN (Service Principal Name) — имя участника службы — уникальное имя, по которому идентифицируется экземпляр сервиса. Это способ сопоставить учетную запись Windows, ответственную за запуск экземпляра службы, с сервером и службой.
• UPN (User Principal Name) — логин пользователя. Имя, сокращенное относительно полного имени пользователя. Пример: user@domain.ru.
• KDC (Key Distribution Center) — сервер аутентификации в инфраструктуре Kerberos. Контроллер домена.
• TGS (Ticket Grant Service) - билет на предоставление доступа к сервису. В нашем случае это билет kerberos на доступ в приложение.
• Keytab - файл, содержащий одну или несколько пар SPN и долговременного ключа шифрования.

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

После успешной проверки kerberos-билета от пользователя:

1. Приложение извлекает из него логин, например, user@msk.example.com. Логин, получаемый из билета, соответствует атрибуту sAMAccountName в Active Directory.

2. Приложение производит последовательный поиск нескольких вариантов логина во внутренней базе данных:

   • user
   • user@MSK.EXAMPLE.COM
   • user@MSK
   • MSK\user

3. Приложение прекращает дальнейший поиск при первом найденном варианте логина и разрешает вход под этим пользователем.

   Если найдено несколько пользователей с идентичными логинами, например два user (аномальная ситуация) или не один вариант логина не найден, будет возвращена ошибка.

Включить или отключить регистронезависимость логинов можно в конфигурационном файле dbaccess.properties (параметр login.casesensitive, раздел Аутентификация и авторизация).

Также расширить правила поиска логина внутри системы можно с помощью конфигурации файла realm-rules-config.xml (см. Настройка соответствия имен доменов и Realm. Конфигурационный файл realm-rules-config.xml).

Требования к инфраструктуре для использования Kerberos-аутентификации

Требования к инфраструктуре для использования прозрачной аутентификации с использованием протокола Kerberos (дополнение к техническим требованиям эксплуатации):

• Наличие KDC (Key Distribution Center) - сервер аутентификации в инфраструктуре Kerberos, контроллер домена Active Directory под управлением ОС MS Windows Server 2008 R2 и выше;
• Рабочие станции пользователей под управлением ОС MS Windows XP выше;
• Используемый браузер Microsoft Edge, Mozilla Firefox 3.6 и выше, Google Chrome 18,19 и выше;
• Рабочие станции пользователей включены в домен, пользователи используют доменные учетные записи;
• Логины пользователей в системе должны соответствовать логинам в AD (как правило, для этого используется механизм импорта оргструктуры из Active Directory);
• При использовании разветвленной доменной инфраструктуры, в случае если домен пользователя отличается от домена KDC, между доменами должны быть установлены двусторонние доверительные отношения на уровне лесов (Forest Trust).

Для сервера приложения не обязательно:

• иметь доступ до контроллеров домена, если только одновременно не настроена LDAP-аутентификация на форме;
• принадлежать домену, в котором настраивается аутентификация;
• запускаться под доменной учетной записью.

Прозрачная аутентификация может работать на удаленном рабочем столе (пользователь должен войти под доменной учетной записью).

Настройка Kerberos-аутентификации

Данные, используемые в документации для примера настройки

Данные	Значение	Описание
Домен	msk.example.com	Полное имя домена аутентификации (домен, в котором зарегистрированы пользователи)
Второй домен	spb.example.com	Полное имя второго домена аутентификации (используется для примеров с мультидоменной конфигурацией)
Сервер приложений	srv-app.local	DNS A-запись сервера приложения
Ссылка на приложение	https://support.msk.example.com	Ссылка, по которой пользователи работают в приложении. Домен не обязан совпадать с доменом аутентификации и взят для примера
Служебная учетная запись	naumen-spnego@msk.example.com	Пользователь, к которому привязывается SPN
Пароль служебной учетной записи	myP@ssw0rd	Пароль пользователя, к которому привязывается SPN. Используется при генерации keytab-файла
Пользователь-клиент	myuser@msk.example.com	Пользователь-клиент приложения
Realm	MSK.EXAMPLE.COM, SPB.EXAMPLE.COM	Область аутентификации Kerberos. Записывается заглавными буквами. Соответствует полному имени домена аутентификации

Создание SPN и keytab-файла

Чтобы настроить сервер аутентификации в инфраструктуре Kerberos (Key Distribution Center), выполните следующие действия:

1. Создайте учетную запись пользователя (User Logon Name = naumen-spnego) в Active Directory с помощью Active Directory Users and Computers:

   • При создании снимите флажок User must change password at next logon;
   • Введите и запомните пароль (myP@ssw0rd).

   Убедитесь, что в Active Directory нет учетной записи компьютера с таким же именем.

2. В параметрах созданного аккаунта (Account options) включите AES128 kerberos шифрование, в Java 17 это минимально допустимый тип шифрования kerberos.

   При переходе на Java 17 перестало поддерживаться шифрование arcfour-hmac, поэтому требуется перегенерировать keytab-файл, если в нем использовано только такое шифрование

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

   ktpass -princ HTTP/srv-app.local@MSK.EXAMPLE.COM -crypto AES128-SHA1 -mapuser naumen-spnego@msk.example.com -pass myP@ssw0rd -SetPass -out c:\TEMP\naumen.keytab

   где

   • -princ HTTP/srv-app.local@MSK.EXAMPLE.COM — principal name, сформированный по следующему принципу:

     • HTTP/srv-app.local — SPN, составленный из специального префикса HTTP/ (не указывать HTTPS!) и имени сервера, на котором работает приложение
     • @MSK.EXAMPLE.COM — реалм, для которого выписывается keytab. Указывается название домена большими буквами..
   • -crypto AES128-SHA1 — тип шифрования ключа в keytab-файле, рекомендуемые значения AES128-SHA1 или AES256-SHA1, выбранный тип шифрования должен быть включен в параметрах служебной учетной записи
   • -mapuser naumen-spnego@msk.example.com — имя служебной учетной записи, к которой привязывается SPN.
   • -pass myP@ssw0rd — пароль служебной учетной записи, указанной после опции -mapuser. Если пароль не совпадает с действительным паролем этой учетной записи, то keytab считается невалидным.
   • -SetPass — отключение сброса пароля на служебной учетной записи к значению указанному после опции -pass.
   • -out c:\TEMP\naumen.keytab — путь, по которому будет сформирован keytab-файл

   Если в профиле пользователя AD включены два типа шифрования, то тип шифрования ключа в keytab-файле нужно указать как -crypto ALL

   В результате будет создан файл naumen.keytab.

   После генерации keytab-файла пароль служебной учетной записи naumen-spnego не должен меняться, иначе keytab-файл окажется невалидным. При необходимости сменить пароль учетной записи перегенерируйте keytab-файл повторным запуском указанной выше команды.

   Имя хоста в SPN должно соответствовать полному доменному имени сервера приложения.

4. Чтобы использовать для доступа к серверу приложения дополнительные имена (при наличии дополнительных записей DNS типа CNAME), зарегистрируйте SPN на основное DNS-имя и добавьте SPN для всех дополнительных записей типа CNAME, с помощью команды:

   setspn -A HTTP/support.msk.example.com@MSK.EXAMPLE.COM msk.example.com\naumen-spnego

   где support.msk.example.com — CNAME на основной домен srv-app.local

5. Выведите список SPN, привязанных к учетной записи, и убедитесь в их корректности с помощью команды:

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

6. Безопасно скопируйте keytab-файл на сервер приложения, например, программой WinSCP, в любой каталог, например, /opt/naumen/nausd4/conf/naumen.keytab.

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

Настройка сервера приложений

Настройка krb5.conf (krb5.ini)

Имя области аутентификации (REALM) задается в системном файле /etc/krb5.conf для Linux, C:\Windows\krb5.ini для Microsoft Windows.

В файле krb5.conf (krb5.ini) пропишите имя области аутентификации (имя домена заглавными буквами):

[libdefaults]
   default_realm = MSK.EXAMPLE.COM

Настройка параметров аутентификатора (dbaccess.properties)

Описание всех параметров настройки аутентификации в файле dbaccess.properties (раздел Аутентификация и авторизация).

Чтобы настроить параметры аутентификатора в конфигурационном файле dbaccess.properties:

1. Добавьте аутентификатор SPNEGO в список используемых типов аутентификаторов.

   ru.naumen.core.authentication.authenticators=SPNEGO,INTERNAL

2. Укажите необходимые параметры аутентификатора (SPN, путь до keytab-файла):

   ru.naumen.core.authentication.authenticators=SPNEGO,INTERNAL
   ru.naumen.core.authentication.spnego-authenticator.service-principal=HTTP/srv-app.local
   ru.naumen.core.authentication.spnego-authenticator.keytab=file:/opt/naumen/nausd4/conf/naumen.keytab
   ru.naumen.core.authentication.spnego-authenticator.debug=true

   • ru.naumen.core.authentication.spnego-authenticator.service-principal - SPN, для которого выписан keytab. Возможно дополнительно явно указать realm, тогда можно не указывать default_realm в krb5.conf (krb5.ini). Realm указывается через символ @ после имени SPN: HTTP/srv-app.local@MSK.EXAMPLE.COM.

   • ru.naumen.core.authentication.spnego-authenticator.keytab - путь до keytab-файла, путь обязательно должен содержать префикс file:. Пример значения параметра для Windows: file:C:/naumen/nausd4/conf/naumen.keytab. Также можно использовать переменную, содержащую путь к каталогу с конфигурационными файлами приложения ${ext.prop.dir}: file:${ext.prop.dir}/naumen.keytab.

     В пути до keytab-файла рекомендуется использовать прямой слеш / не зависимо от используемой операционной системы. Обратный слеш \ в сочетании с некоторыми символами может быть интерпретирован Java как управляющий символ.

   • ru.naumen.core.authentication.spnego-authenticator.debug - рекомендуется устанавливать в true. Дополнительный вывод не может значительно увеличить объем журналов приложения.
3. Перезапустите сервис приложения, чтобы изменения конфигурации вступили в силу.

Настройка браузера

Настройка рабочего места пользователя сводится к конфигурации браузера.

Mozilla Firefox

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

1. Запустите Mozilla Firefox.
2. В адресной строке введите about:config и нажмите Enter.
3. В поле "Поиск" (Filter) введите negotiate, чтобы ограничить список опций.
4. Дважды кликните на строке с параметром network.negotiate-auth.trusted-uris.

5. В диалоговом окне введите:

   • Чтобы разрешить SPNEGO аутентификацию только по конкретной ссылке, введите полностью домен из ссылки (например, support.msk.example.com).
   • Чтобы разрешить SPNEGO аутентификацию для целого домена, введите имя домена с точкой в начале (например, .msk.example.com).
   • Чтобы разрешить SPNEGO аутентификацию для нескольких доменов, введите их через запятую. После запятой можно ставить пробел.

Google Chrome

Настройка браузера заключается в добавлении параметра запуска --auth-server-allowlist="*.msk.example.com".

До 86 версии Chrome этот параметр назывался --auth-server-whitelist.

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

1. Кликните правой кнопкой мыши на ярлыке Google Chrome.
2. Выберите "Свойства".

3. В поле "Объект" к строке запуска браузера допишите --args --auth-server-allowlist="*.msk.example.com".

   Пример:

   "C:\Program Files\Google\Chrome\Application\chrome.exe" --args --auth-server-allowlist="*.msk.example.com"

Альтернативным вариантом настройки является настройка Edge по инструкции для соответствующего браузера на одной рабочей станции с Chrome. В этом случае Google Chrome берет системные настройки свойств браузера (Internet Options) и не требует запуска с дополнительными параметрами.

Microsoft Edge

Настройка браузера заключается в добавлении сайта в местную сеть Интранет (Intranet).

Настройка браузера Microsoft Edge выполняется через панель управления Windows.

Добавление сайта в местную сеть Интранет (Intranet)

Чтобы выполнить настройку:

1. Откройте панель управления (Control Panel) и выберите "Свойства браузера" (Internet Options).
2. Перейдите на вкладку "Безопасность" (Security).
3. Выберете зону "Местная интрасеть" (Local Intranet) и нажмите кнопку Узлы (Sites).
4. В диалоговом окне убедитесь, что флажок "Автоматически определять принадлежность к интрасети" (Include all sites that bypass the proxy server) установлен и нажмите кнопку "Дополнительно" (Advanced).
5. В диалоговом окне "Местная интрасеть" (Local Intranet)" добавьте все относительные доменные имена, которые будут использоваться в сети Интранет (например, *.msk.example.com или просто support.msk.example.com).
6. Нажмите "OK" и закройте диалоговое окно.

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

Проверки при ошибке

Если после добавления сайта в сеть Интранет при переходе в приложение возникает ошибка, выполните проверки:

1. Установлена ли автоматическая аутентификация для зоны Intranet:

   • перейдите на вкладку "Безопасность" (Security), выберете зону "Местная интрасеть" (Local Intranet) и нажмите кнопку "Другой..."(Custom Level);
   • в диалоговом окне "Параметры безопасности" (Security Settings) прокрутите вниз список к секции "Проверка подлинности пользователя" (User Authentication) и выберете "Автоматический вход в сеть только в зоне интрасети" (Automatic logon only in Intranet zone). Эта настройка позволит пользователям избавиться от повторного ввода логина и пароля;
   • нажмите "OK", чтобы закрыть диалоговое окно.

2. Проверьте разрешение на использование встроенной аутентификации:

   • перейдите на вкладку "Дополнительно" (Advanced);
   • в разделе "Безопасность" (Security) установите флажок "Разрешить встроенную проверку подлинности Windows" (Enable Integrated Windows Authentication);
   • нажмите кнопку "OK".

Yandex Browser

Yandex Browser для организаций

Редакция "Yandex Browser для организаций" отличается возможностью централизованной настройки на уровне групповых политик.

Настройка прозрачной аутентификации для этой редакции описана в официальной документации (ссылка на документацию).

Yandex Browser "Домашняя редакция"

Настройка заключается в добавлении параметра запуска --auth-server-whitelist="*.msk.example.com".

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

1. Наведите курсор на ярлык Yandex Browser и нажмите правую клавишу мыши.
2. В контекстном меню выберите "Свойства".

3. В поле "Объект" к строке запуска браузера допишите --args --auth-server-whitelist="*.msk.example.com".

   Пример:

   "C:\Users\Username\AppData\Local\Yandex\YandexBrowser\Application\browser.exe" --args --auth-server-whitelist="*.msk.example.com"

Альтернативным вариантом настройки является настройка Internet Edge по инструкции для соответствующего браузера на одной рабочей станции с Yandex Browser. В этом случае Yandex Browser берет системные настройки свойств браузера (Internet Options) и не требует запуска с дополнительными параметрами.

Дополнительные настройки 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 должен находиться в каталоге c конфигурационными файлами приложения. Путь к этому каталогу указывается в java-опции -Dext.prop.dir — Linux, Windows.

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

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

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

Настоятельно рекомендуется настроить логирование ошибок аутентификации. Логирование ошибок несущественно увеличивает файл журнала sdng.log, поэтому рекомендуется включить его на постоянной основе.

Отображение ошибок аутентификации в логе приложения настраивается в конфигурационном файле log4j2.properties.

За вывод в лог информации о процессе аутентификации отвечают следующие настройки.

Поиск авторизованного через службу пользователя в БД SD:

logger.authdb.name=ru.naumen.sec.server.employee
logger.authdb.level=DEBUG 

Общие части аутентификаторов:

logger.springauth.name=org.springframework.security.authentication
logger.springauth.level=DEBUG

Логеры Kerberos/SPNEGO аутентификатора

logger.secserver.name=ru.naumen.sec.server
logger.secserver.level=DEBUG
logger.sepnego.name=ru.naumen.sec.server.spnego
logger.sepnego.level=DEBUG

Логеры LDAP & AD аутентификаторов

logger.ldap.name=org.springframework.security.ldap
logger.ldap.level=DEBUG
logger.ldapsearch.name=org.springframework.security.ldap.search
logger.ldapsearch.level=DEBUG
logger.ldapauth.name=org.springframework.security.ldap.authentication
logger.ldapauth.level=DEBUG
logger.nauldap.name=ru.naumen.core.server.ldap
logger.nauldap.level=DEBUG

Указанные настройки включены в шаблоне файла log4j2.properties, который можно скачать с сайта NAUMEN (ссылка для скачивания).

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

Для вывода дополнительных сообщений в 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.

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

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

• Утилита klist

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

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

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

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

• Любой текстовый редактор.

  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-файла не изменилось, перезапуск приложения не требуется.