Интеграция KUMA с ALD Pro
Интеграция является не официальной
Документация по службе каталогов для Linux Astra ALD Pro: https://astra.ru/software-services/application-software-astra-group/ald-pro/#docs
Настройки выполняются по налогии со статьей: https://kb.kuma-community.ru/books/integracii/page/integraciia-kuma-s-active-directory-ad-nvg
При интеграции с AD/ADFSALD Pro важно иметь единое время на системах, настоятельно рекомендуется настроить NTP
корневой домен леса - example.comконтроллер домена - dc-01.example.comдочерний домен - subdomain.example.com
В дочыбернем домене созданы:
OU «KUMA subdomain»Universal группы безопасности: «kuma_subdomain_analyst», «kuma_subdomain_admin», «kuma_subdomain_operators»Пользователи: subdom_admin, subdom_analyst
Пользователи являются членами соответствующих групп:
Настройки KUMA
Base DN – корневой домен (не обязательно весь корневой домен, зависит от вашего AD)
URL – контроллеры корневого домена, порт глобального каталога (обязательно)
Важно:
Все группы доступа должны быть UNIVERSALУ пользователей в AD должно быть заполнен атрибутemail
Далее – для каждого тенанта указываете DistinguishedName групп, соответствующих правам доступа.
Информация по ролям и их возможностям: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/218031.htm
Важный момент:
Предоставление доступа происходит по принципу «наименьших прав». Если учетка пользователя одновременно состоит нескольких в группах одного тенанта.Например: kuma-analysts и kuma-admins, то пользователь получит права аналитика. Поэтому, при переводе работников из операторов в аналитики или аналитиков в админы, необходимо не только добавить пользователя в соответствующую новую группы, но еще и удалить из старой группы.
Результат
Для доменной аутентификации, как таковой учетки в KUMA не требуется. Когда все настроено, вводится доменный логин и пароль и в этот момент KUMA биндится к LDAP.
При аутентификации, пользователь вводит в консоль свою доменную учетку в формате UPN (user@example.com) и, на основании членства этой учетки в той или иной группе, пользователю предоставляется доступ к разным тенантам с указанными правами.
Залогинившись под доменной учеткойsubdom_analyst@subdomain.example.comПолучаем права роли analyst в тенанте Main
Пример входа в KUMA с доменной учетной записью (kuma-admin@sales.lab):
Права API можно выдавать только для внутренних пользователей, не из AD
Порты AD
Порт3268. Этот порт используется для запросов, специально предназначенных для глобального каталога. Запросы LDAP, отправленные на порт 3268, можно использовать для поиска объектов во всем лесу. Однако могут быть возвращены только атрибуты, помеченные для репликации в глобальный каталог. Например, отдел пользователя не может быть возвращен через порт 3268, так как этот атрибут не реплицируется в глобальный каталог.Порт389. Этот порт используется для запроса информации с локального контроллера домена. Запросы LDAP, отправленные на порт 389, можно использовать для поиска объектов только в домашнем домене глобального каталога. Однако запрашивающее приложение может получить все атрибуты этих объектов. Например, запрос на порт 389 может быть использован для получения отдела пользователя.Приинтеграции FreeIPA и группы для учетных записейSSL необхзаводимо использовать сертификат Active Directory. В KUMA поддерживаются открытые ключи сертификата X.509вBase64. Стандартный порт LDAPS -636.
Полезные ком виде:
uid=is.ldap.usr,cn=users,cn=accounts,dc=company,dc=com