Настройка среды единого входа (SSO) на основе Kerberos

В MULTIFACTOR SelfService Portal реализована поддержка Kerberos-аутентификации, обеспечивающая прозрачный вход пользователей (Single Sign-On) в корпоративной среде.

При доступе к приложению браузер автоматически получает сервисный билет (Service Ticket) от контроллера домена и передаёт его в HTTP-заголовке Authorization: Negotiate.

Приложение обрабатывает полученный Kerberos-токен и выполняет его криптографическую проверку с использованием keytab-файла, содержащего ключ сервисной учётной записи, зарегистрированной в Active Directory.

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

При этом передача пароля пользователя по сети не осуществляется.

Схема работы

1. Пользователь выполняет вход в ОС Windows с учетными данными домена Active Directory (AD).
2. Центр распространения ключей (KDC) , функционирующий на контроллере AD, выдает билет для получения билетов (TGT) после успешной аутентификации.
3. TGT сохраняется в кэше подсистемы безопасности Windows (LSA) рабочей станции для последующего использования.
4. При открытии URL https://app.example.com браузер с использованием механизма согласования протоколов (SPNEGO) запрашивает сервисный билет для целевого приложения и передает его в заголовке Authorization: Negotiate, обеспечивая единый вход (SSO) .
5. Обратный прокси-сервер (Nginx) транслирует запрос в приложение без изменения заголовка.
6. Приложение SelfService Portal (SSP) выполняет криптографическую проверку токена с использованием файла ключей сервисной учетной записи (keytab) 
7. Из расшифрованного токена извлекается идентификатор субъекта Kerberos  пользователя в формате user@EXAMPLE.COM (UPN) для идентификации в системе.
8. После чего пользователь получает доступ к SSP без повторного ввода логина и пароля.

Состав окружения и требования

Типовой состав окружения

Требования

cat /etc/resolv.conf

nslookup <AD_DOMAIN>
nslookup <DC_HOSTNAME>

nc -zv <DC_HOST> 88
nc -zv <DC_HOST> 389
nc -zv <DC_HOST> 636

chronyc tracking

apt install chrony

/etc/chrony/chrony.conf

server <DC_HOST> iburst prefer

systemctl restart chrony

chronyc sources

Для настройки среды единого входа (SSO) на основе Kerberos Вам потребуется установить и настроить MULTIFACTOR SelfService Portal

Установка и конфигурация Kerberos клиента

Установка компонента

Выполните установку пакета krb5-user используя следующую команду:

apt install krb5-user

Конфигурация Kerberos

Файл конфигурации Kerberos находится по пути /etc/krb5.conf.
Откройте его в редакторе:

sudo nano /etc/krb5.conf

После открытия файла приведите его к следующему виду:

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = true
 rdns = false

[realms]
 EXAMPLE.COM = {
     kdc = dc01.example.com
     admin_server = dc01.example.com
 }

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

Настройка переменной окружения KRB5_KTNAME

Для того чтобы MULTIFACTOR SelfService Portal мог использовать keytab-файл, расположенный не по пути стандартному пути, необходимо добавить переменную окружения KRB5_KTNAME в конфигурацию systemd-сервиса. Эта переменная указывает стандартному механизму Kerberos MIT Krb5 на файл ключей, который будет использоваться для расшифровки входящих билетов.

Отредактируйте файл конфигурации systemd-сервиса

sudo nano /etc/systemd/system/ssp.service

Добавьте переменную в секцию [Service]

Environment="KRB5_KTNAME=/opt/multifactor/kerberos/app.keytab"

Файл должен выглядеть следующим образом:

[Unit]
Description=Self Service Portal

[Service]
WorkingDirectory=/opt/multifactor/ssp/app
ExecStart=/usr/bin/dotnet /opt/multifactor/ssp/app/MultiFactor.SelfService.Linux.Portal.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
TimeoutStopSec=90
SyslogIdentifier=ssp-service
User=mfa
Environment=ASPNETCORE_ENVIRONMENT=production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment="KRB5_KTNAME=/opt/multifactor/kerberos/app.keytab"
[Install]
WantedBy=multi-user.target

Затем сохраните файл и перезапустите службы:

sudo systemctl daemon-reload
sudo systemctl restart ssp.service

Проверка работы Kerberos

После настройки клиента Kerberos необходимо проверить корректность его работы. Ниже приведены основные команды для управления и проверки билетов.

Получение билета TGT (Ticket Granting Ticket)

Для получения билета используйте команду kinit, указав имя пользователя Active Directory:

kinit <AD_USER>
#kinit ivanov@EXAMPLE.COM

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

Проверка полученных билетов

Для просмотра информации о текущих билетах Kerberos используйте команду:

klist

Вывод команды будет иметь следующий вид:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ivanov@EXAMPLE.COM

Valid starting       Expires              Service principal
03/25/2026 10:00:00  03/26/2026 10:00:00  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Команда отображает:

• Кэш билетов
• Основного субъекта (principal)
• Время начала и окончания действия билетов

Очистка кэша билетов

Для удаления всех полученных билетов и завершения сеанса Kerberos выполните:

kdestroy

Эта команда очищает кэш билетов, что эквивалентно «выходу из системы» Kerberos.

Создание сервисного аккаунта в AD для Kerberos аутентификации Nginx

Сервисный аккаунт (Service Account) используется веб-сервером Nginx для проверки Kerberos-тикетов при аутентификации пользователей. Аккаунт не предназначен для интерактивного входа и имеет строгие ограничения в соответствии с принципами минимально необходимых привилегий.

Требования к сервисному аккаунту

Создание пользователя

Среда выполнения

• Контроллер домена: Windows Server 2019
• Оснастка: Active Directory Users and Computers

Рекомендации по безопасности

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

Проверка создания аккаунта

Для верификации корректного создания учетной записи выполните в PowerShell на контроллере домена:

Get-ADUser svc_ssp -Properties PasswordNeverExpires, CannotChangePassword, ServicePrincipalNames, LogonWorkstations

Результат должен быть следующим:

• PasswordNeverExpires — True.
• CannotChangePassword — True.
• ServicePrincipalNames — должен содержать настроенные SPN (если они уже зарегистрированы).
• LogonWorkstations — содержит имя сервера Nginx.

Настройка Intranet Zone для поддержки Kerberos SSO

Для корректной работы Single Sign-On (SSO) на базе Kerberos веб-браузеры должны доверять сайту и передавать учетные данные текущего пользователя. 

Поэтому необходимо провести настройку доверенных зон и параметров аутентификации через групповые политики (Group Policy) для браузеров Internet Explorer, Chrome и Edge.

Важно 

Kerberos-аутентификация в браузере работает только для сайтов, добавленных в доверенные зоны (Intranet Zone).

Среда настройки

Настройка назначения сайта в зону (Site to Zone Assignment)

Данная политика добавляет сайт в зону локальной интрасети (Intranet Zone):

Откройте следующий путь в Group Policy:

Computer Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page

и включите параметр Site to Zone Assignment List.

Далее нажмите Show.

Добавьте запись:

• Name of item: http://app.example.com — URL или домен сайта, который необходимо добавить в доверенную зону. Можно указывать как полный адрес, так и шаблон (например, *.example.com)
• Value: 1  — код зоны безопасности: 1 — зона локальной интрасети (Intranet Zone)

Включение автоматической аутентификации в зоне Intranet

Откройте следующий путь в Group Policy:

User Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → Intranet Zone

и включите параметр Logon → Automatic logon with current username and password

Настройка для браузеров Chrome и Edge

Браузеры Google Chrome и Microsoft Edge (на базе Chromium) используют собственные политики для настройки Kerberos-аутентификации, но могут наследовать настройки Internet Explorer при определенных условиях.

Политики Chrome / Edge

Также политики можно задать через реестр:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthServerAllowlist"="*.example.com"
"AuthNegotiateDelegateAllowlist"="*.example.com"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"AuthServerAllowlist"="*.example.com"
"AuthNegotiateDelegateAllowlist"="*.example.com"

Проверка настроек

После применения групповых политик выполните проверку:

gpupdate /force

1. Откройте браузер и перейдите по адресу http://app.example.com.
2. Проверьте, что аутентификация прошла автоматически (без запроса логина и пароля).
3. В инструментах разработчика браузера (F12) на вкладке Network проверьте наличие заголовка Authorization: Negotiate.

Создание Service Principal Name (SPN) для Nginx

Service Principal Name (SPN) связывает сервис (в данном случае Nginx) с учетной записью сервисного аккаунта. SPN необходим клиентам для идентификации сервиса при запросе Kerberos-тикетов.

Создание SPN

Выполните команду от имени администратора:

setspn -S HTTP/app.example.com svc_ssp

Проверка SPN

Для проверки корректности создания выполните:

setspn -L svc_ssp

Вывод должен иметь следующий вид:

Registered ServicePrincipalNames for CN=svc_ssp,...
        HTTP/app.example.com

Генерация и установка keytab для Nginx

Keytab-файл содержит ключи сервисного аккаунта и позволяет Nginx выполнять Kerberos-аутентификацию без интерактивного ввода пароля.

Генерация keytab на контроллере домена

Выполните команду от имени администратора:

ktpass ^
 -out app.keytab ^
 -princ HTTP/app.example.com@EXAMPLE.COM ^
 -mapuser svc_ssp@EXAMPLE.COM ^
 -crypto AES256-SHA1 ^
 -ptype KRB5_NT_PRINCIPAL ^
 -pass *

AES256-SHA1 (рекомендуется)
AES128-SHA1
RC4-HMAC-NT

Установка keytab на сервер Nginx

Создайте следующую директорию:

sudo mkdir /opt/app/kerberos

Скопируйте сгенерированный файл на сервер Nginx:

cp /path/to/app.keytab /opt/app/kerberos/app.keytab

Настройте права доступа следующим образом:

chown srv_user:ssp-group /opt/app/kerberos
chmod 750 /opt/app/kerberos
chmod 640 /opt/app/kerberos/app.keytab

Проверка keytab

Просмотр содержимого keytab:

klist -k /opt/app/kerberos/app.keytab

Ожидаемый вывод: отображение principal и версии ключа.

Проверка получения билета через keytab:

kinit -k -t /opt/app/kerberos/app.keytab HTTP/app.example.com

Проверка доступа от имени пользователя приложения:

sudo -u srv_user klist -k /opt/app/kerberos/app.keytab

Команда подтверждает, что пользователь приложения имеет доступ к чтению keytab.

Признаки успешной проверки:

Конфигурация Nginx для Kerberos-аутентификации

Настройка Nginx в качестве прокси-сервера с поддержкой Kerberos-аутентификации.

Важно

Аутентификация реализована на уровне приложения (не через SPNEGO-модуль Nginx).

Настройка конфигурации

Откройте файл конфигурации для редактирования:

sudo nano /etc/nginx/conf.d/ssp.conf

Конфигурация должна иметь следующий вид:

server {
  # DNS имя сервера с порталом
  server_name app.example.com;

  location / {
    # http://<host>:<port> Kestrel
    proxy_pass         http://localhost:5000;

    proxy_http_version 1.1;
    proxy_set_header   Upgrade $http_upgrade;
    proxy_set_header   Connection keep-alive;
    proxy_set_header   Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_cache_bypass $http_upgrade;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
  }

  listen 80;
}

Данная конфигурация:

• Слушает входящие запросы на порту 80
• Принимает запросы для домена ( в данном случае app.example.com)
• Перенаправляет (проксирует) все запросы на локальный сервер, работающий на порту 5000
• Передает оригинальный заголовок Host и реальный IP-адрес клиента

Настройте и сохраните файл конфигурации и выполните проверку на наличие ошибок:

nginx -t

Вывод должен быть следующим:

nginx: configuration file /etc/nginx/nginx.conf test is successful

Перезапустите Nginx:

systemctl restart nginx

Проверьте статус он должен быть active (running):

systemctl status nginx

Важно

 Kerberos-аутентификация (механизм Negotiate/GSSAPI) не работает с HTTP/2, так как требует особенностей HTTP/1.1 (connection-based authentication). Поэтому HTTP/2 должен быть отключён для данного virtual host.

Типовые проблемы

Clock skew too great

chronyc tracking

Server not found in Kerberos database

setspn -L svc_ssp

klist -k /opt/app/kerberos/app.keytab

Полная проверка среды

Выполните по порядку: