Интеграция KUMA с Active Directory (AD)
При интеграции с AD/ADFS важно иметь единое время на системах, настоятельно рекомендуется настроить 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 может быть использован для получения отдела пользователя.
- При интеграции с SSL необходимо использовать сертификат Active Directory. В KUMA поддерживаются открытые ключи сертификата X.509 в Base64. Стандартный порт LDAPS - 636.
Полезные команды
