Настройка доступа по технологии единого входа (SSO)

Технология единого входа (Single Sign-On, SSO) на основе Kerberos позволяет пользователям автоматически аутентифицироваться в приложении «Менеджер службы каталогов» (DSM) без ввода логина и пароля, используя существующие доменные учетные данные.

В данной инструкции приводится пример настройки SSO для следующей конфигурации машин:

контроллер домена (dc1.elles.inno.tech в примерах) — сервер с развернутым контроллером домена Эллес, на котором привязывается SPN (Service Principal Name) в формате HTTP/jump-server1.elles.inno.tech к компьютерной учетной записи jump-сервера, а также генерируется keytab-файл, содержащий секретный ключ, соответствующий этому SPN, для последующей аутентификации сервиса DSM;
jump-сервер (jump-server1.elles.inno.tech в примерах) — сервер с развернутым экземпляром приложения DSM, использующий keytab для расшифровки и проверки Kerberos-билетов, поступающих от клиентов;
клиентская машина — рабочая станция, например, под управлением ОС Astra Linux, введенная в домен elles.inno.tech, с браузером Chromium, настроенным для автоматической передачи билетов Kerberos при обращении к сервису DSM.

Приводимые в инструкции команды требуют разных уровней прав в зависимости от задачи:

на контроллере домена требуется учетная запись с правами администратора домена (в примерах используется учетная запись Administrator);
на jump-сервере достаточно учетной записи с правами записи в /opt/dsm/ — должен быть доступ к файловой системе и праву sudo для смены владельца/прав доступа к keytab;
на клиентской машине (например, при kinit, klist, настройке /etc/krb5.conf) достаточно обычного пользователя домена, имеющего действительный билет Kerberos (TGT) — права администратора не требуются, если только не изменяются системные файлы (например, /etc/krb5.conf требует root).

Проверяйте наличие TGT перед каждым шагом с помощью команды klist.

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

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

Настройка на контроллере домена Эллес.
Настройка на jump-сервере с развернутым экземпляром приложения DSM.
Настройка на клиентской машине.

Настройка на контроллере домена

На контроллере домена Эллес:

Привяжите SPN для сервиса HTTP к учетной записи jump-сервера.
Например, используйте LDIF-файл для внесения требуемых изменений:

создайте LDIF-файл (в примере — http_spn.ldif):

dn: CN=JUMP-SERVER1,CN=Computers,DC=elles,DC=inno,DC=tech (1)
changetype: modify (2)
add: servicePrincipalName (3)
servicePrincipalName: HTTP/JUMP-SERVER1.elles.inno.tech (4)
servicePrincipalName: HTTP/JUMP-SERVER1 (5)

В примере:

1	Указывает объект в каталоге, к которому применяются изменения (в примере — компьютерная учетная запись `JUMP-SERVER1` в контейнере `Computers` домена `elles.inno.tech`).
2	Операция изменяет существующий объект.
3	Добавляет новое значение SPN к атрибуту объекта, не удаляя существующие.
4	Основной идентификатор SPN для SSO, соответствующий FQDN сервера; клиенты используют его для запроса Kerberos-билета при обращении к http://jump-server1.elles.inno.tech.
5	Дополнительный идентификатор SPN для совместимости с клиентами, которые обращаются к серверу по короткому имени (без домена), например http://JUMP-SERVER1.

примените изменения, например, с помощью утилиты ldapmodify:
ldapmodify -v -Y GSSAPI -f http_spn.ldif
Убедитесь, что команда завершилась с сообщением:
modifying entry "CN=JUMP-SERVER1,CN=Computers,DC=elles,DC=inno,DC=tech"
Если утилита ldapmodify отсутствует, установите ее:

sudo apt install ldap-utils

Или используйте подкоманду samba-tool spn add с указанием samAccountName учетной записи jump-сервера. Например:

samba-tool spn add HTTP/JUMP-SERVER1.elles.inno.tech JUMP-SERVER1$
Added SPN successfully for JUMP-SERVER1$

Проверьте, что SPN привязан корректно:

samba-tool spn list JUMP-SERVER1$

Ожидаемый вывод:

User CN=JUMP-SERVER1,CN=Computers,DC=elles,DC=inno,DC=tech has the following servicePrincipalName:
	 HTTP/JUMP-SERVER1.elles.inno.tech
	 HTTP/JUMP-SERVER1

Создайте keytab-файл для сервиса HTTP.
Например:

sudo samba-tool domain exportkeytab /tmp/2http.keytab \
    --principal=HTTP/JUMP-SERVER1.elles.inno.tech

Скопируйте keytab-файл на jump-сервер с DSM доступным способом.

Убедитесь, что на jump-сервере файл доступен для пользователя, от имени которого запущен сервис dsm.

Настройка на jump-сервере с DSM

На jump-сервере с развернутым экземпляром приложения DSM:

Убедитесь, что на сервере корректно настроена аутентификация Kerberos в рамках домена.
Пример содержимого файла /etc/krb5.conf:

[libdefaults]
default_realm = ELLES.INNO.TECH
canonicalize = true

[realms]
    ELLES.INNO.TECH = {
        kdc = elles.inno.tech
        admin_server = elles.inno.tech
        default_domain = elles.inno.tech
}

[domain_realm]
    elles.inno.tech = ELLES.INNO.TECH
    .elles.inno.tech = ELLES.INNO.TECH

В конфигурации DSM в файле /opt/dsm/application.yml настройте аутентификацию Kerberos с использованием SPN и созданного keytab-файла в разделе kerberos:

kerberos:
  service-principal: HTTP/JUMP-SERVER1.elles.inno.tech (1)
  keytab-location: /opt/dsm/2http.keytab (2)
  cache-location: /tmp/krb5cc_0 (3)

В примере:

1	Идентификатор сервиса, который DSM использует для аутентификации клиентов через Kerberos; должен совпадать с SPN, привязанным к компьютерной учетной записи в каталоге.
2	Локальный путь к keytab-файлу с ключом, соответствующим указанному SPN; DSM использует его для расшифровки Kerberos-билетов, полученных от клиентов.
3	Локальный путь к временному кэшу билетов Kerberos.

Пример файла application.yml:

ldap:
  connection:
    host: dc1.elles.inno.tech
    port: 389
    pool-size: 5

authentication:
  roles:
    admin:
      groups:
        anyOf:
          - CN=Administrators,CN=Builtin,DC=elles,DC=inno,DC=tech
          - CN=Domain Admins,CN=Users,DC=elles,DC=inno,DC=tech
    user:
      includeToAll: true

ellesmon:
  monitoring-connection:
    host: dc1.elles.inno.tech
    port: 8083

gpm:
  host: dc1.elles.inno.tech
  admx:
    path: elles.inno.tech\Policies\PolicyDefinitions
  policies-path: elles.inno.tech\Policies

grpc:
  enabled: true
  connection:
    port: 8443
    spn-prefix: ldap
  security:
    enabled: false

kerberos:
  service-principal: HTTP/JUMP-SERVER1.elles.inno.tech
  keytab-location: /opt/dsm/2http.keytab
  cache-location: /tmp/krb5cc_0

Убедитесь, что keytab-файл доступен и имеет корректные права.
Для применения изменений в конфигурации перезапустите сервис dsm:
sudo systemctl restart dsm.service

Настройка клиентской машины (Linux)

На клиентской машине:

Чтобы обеспечить стабильную работу SSO с Kerberos, добавьте в файл /etc/hosts записи, явно сопоставляющие IP-адреса с FQDN и короткими именами контроллера домена и jump-сервера.
Например:
```
10.19.0.38    dc1.elles.inno.tech dc1 ELLES.INNO.TECH
10.19.0.36    jump-server1.elles.inno.tech jump-server1
```
Убедитесь, что на клиентской машине корректно настроена аутентификация Kerberos в рамках домена.
Пример файла /etc/krb5.conf:
[libdefaults] forwardable = true dns_lookup_realm = false dns_lookup_kdc = false default_realm = ELLES.INNO.TECH udp_preference_limit = 0 default_ccache_name = FILE:/tmp/krb5cc_%{uid} default_tgs_enctypes = AES256-SHA1 default_tkt_enctypes = AES256-SHA1 permitted_enctypes = AES256-SHA1 [realms] ELLES.INNO.TECH = { default_domain = elles.inno.tech kdc = dc1.elles.inno.tech:88 admin_server = dc1.elles.inno.tech:88 } [domain_realm] elles.inno.tech = ELLES.INNO.TECH .elles.inno.tech = ELLES.INNO.TECH
В файле:
- dns_lookup_realm = false и dns_lookup_kdc = false — отключают автоматический поиск realm и KDC через DNS; клиент использует явно указанные значения из файла;
- default_realm — задает имя домена по умолчанию, к которому будут относиться все Kerberos-запросы, если не указано иное;
- default_tgs_enctypes = AES256-SHA1, default_tkt_enctypes = AES256-SHA1, permitted_enctypes = AES256-SHA1 — принудительно ограничивают шифрование для TGT, TGS и всех билетов только алгоритмом AES256, повышая безопасность и исключая устаревшие/слабые алгоритмы (RC4, DES);
- default_ccache_name — определяет путь к файлу кэша билетов Kerberos, где хранятся полученные TGT и TGS; в примере используется временный файл с UID пользователя (FILE:/tmp/krb5cc_%{uid}).
Настройте Chromium для поддержки Negotiate (Kerberos). Для этого создайте директорию и файл политики:
sudo mkdir -p /etc/chromium/policies/managed sudo nano /etc/chromium/policies/managed/sso.json
Содержимое файла:
{ "AuthServerAllowlist": ".elles.inno.tech", "AuthNegotiateDelegateAllowlist": ".elles.inno.tech", "AuthSchemes": "negotiate", "DisableAuthNegotiateCnameLookup": false }
В файле:
- AuthServerAllowlist — задает список серверов, для которых разрешена аутентификация Kerberos; в примере все поддомены .elles.inno.tech будут использовать Negotiate;
- AuthNegotiateDelegateAllowlist — разрешает делегирование учетных данных Kerberos на серверы в домене; необходимо для сценариев, где сервер должен передавать токен дальше (например, при проксировании запросов);
- AuthSchemes — указывает, что Chromium должен использовать протокол Negotiate (Kerberos/NTLM) для аутентификации вместо Basic/Digest; приоритетно Kerberos, если доступен;
- DisableAuthNegotiateCnameLookup — включает проверку CNAME-записей DNS при определении целевого SPN; важно, если сервер доступен по алиасу, и требуется корректное сопоставление SPN с фактическим FQDN.
Перезапустите Chromium.
Убедитесь, что у текущего пользователя есть действительный билет Kerberos (TGT).
Откройте в браузере URL:
```
http://jump-server1.elles.inno.tech:8080
```
Если все настроено корректно, откроется веб-интерфейс DSM без ввода логина и пароля.