§ Інтеграції

Інтеграція UBD з Microsoft Active Directory

Кроки конфігурації: LDAP-з'єднання, синхронізація користувачів, групи, mapping ролей. Типові проблеми.

ЧАС: 10 хв читання СКЛАДНІСТЬ: Середня ОНОВЛЕНО: 2026-05-14

Active Directory залишається основним сховищем облікових записів у більшості українських організацій з більш ніж 100 співробітниками. Правильна інтеграція з AD скорочує адміністративні витрати в 3-5 разів і усуває цілий клас помилок «співробітник звільнений, але доступ залишився».

Огляд AD-інтеграції UBD

UBD підтримує AD-інтеграцію через стандартні протоколи LDAP/LDAPS та (опціонально) Kerberos для single sign-on. Інтеграція складається з трьох частин:

  • Автентифікація: користувач вводить логін/пароль у UBD, UBD перевіряє через AD.
  • Синхронізація користувачів: при першому вході у UBD створюється локальний обліковий запис, прив’язаний до AD.
  • Mapping ролей: AD-групи мапляться на UBD-ролі.

Налаштування LDAP bind

Базові параметри:

  • Сервер LDAP: зазвичай контролер домену, порт 389 (LDAP) або 636 (LDAPS). Для prod завжди LDAPS — інакше пароль передається у відкритому вигляді мережею.
  • Bind DN: сервісний обліковий запис, від імені якого UBD читає AD. Створюється окремо, з мінімальними правами — тільки читання атрибутів користувачів і груп.
  • Base DN: точка у дереві AD, від якої шукати користувачів. Наприклад, OU=Users,DC=company,DC=local.
  • Search filter: правило фільтрації. Стандартне: (&(objectClass=user)(sAMAccountName={0})).

Визначення базового DN

Поширена помилка — використовувати корінь домену як Base DN. Це працює, але повільно і захоплює системні облікові записи. Правильно: точно вказати OU зі звичайними користувачами.

Якщо є кілька OU з користувачами (наприклад, по підрозділах), варіанти:

  • Використати спільний корінь, який охоплює всі OU.
  • Налаштувати кілька LDAP-источників у UBD з різними Base DN.
  • Поєднати користувачів у одну OU (бажано, з організаційних міркувань).

Mapping AD-груп на UBD-ролі

Це найважливіша частина. Помилка тут — і користувач отримує надмірні права.

AD-група UBD-роль Логіка
Domain Admins (не мапиться у UBD) Системні адміни AD ≠ адміни UBD; SoD-правило
UBD-Administrators Administrator Окрема AD-група, керована окремо
UBD-Auditors Auditor Тільки читання, окрема AD-група
UBD-Users User Базова роль звичайних користувачів
HR_Department HR-роль (контекстуальна) Mapping через підрозділ + базова роль

Принцип: не використовувати загальні AD-групи на кшталт «Domain Users» для надання прав у UBD. Створювати окремі групи з префіксом «UBD-», які явно показують призначення.

Стратегії синхронізації

Pull (on-demand)

UBD читає AD при кожному вході користувача. Простіше, але повільніше на масовому вході. Якщо AD недоступне — користувач не може увійти, навіть якщо локальна копія облікового запису є.

Push (на події AD)

AD надсилає події у UBD при зміні користувача. Потребує налаштування AD audit logging і обробника на стороні UBD. Швидше реагує на зміни (зокрема, на звільнення), але складніше у налаштуванні.

Періодична синхронізація

UBD періодично (кожні 5-15 хвилин) опитує AD і оновлює локальний кеш. Найбільш поширений підхід. Баланс простоти і реактивності.

Рекомендоване: періодична синхронізація кожні 5 хвилин + автоматична синхронізація при вході (для критичних змін).

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

1. Помилки TLS

UBD не приймає сертифікат AD-сервера. Найчастіша причина — self-signed сертифікат, не доданий у trust store. Рішення: додати кореневий сертифікат AD CA у trust store UBD-сервера.

Альтернатива (тільки для тесту, не для prod): вимкнути перевірку TLS — це нівелює всю користь LDAPS.

2. Паролі передаються незашифрованими

Налаштовано порт 389 (звичайний LDAP). Паролі видно у трафіку. Виправлення: переключити на 636 (LDAPS) або 389 з StartTLS.

3. Синхронізація неактивних облікових записів

Користувач звільнений, обліковий запис у AD позначений як disabled. UBD не зчитує атрибут userAccountControl і вважає користувача активним. Рішення: у search filter додати перевірку (!(userAccountControl:1.2.840.113556.1.4.803:=2)) — це виключає disabled-облікові записи.

4. Expired паролі

Пароль користувача у AD прострочений. AD відповідає UBD «password expired», але UBD інтерпретує це як неправильний пароль. Рішення: перехоплення цього стану і направлення користувача на сторінку зміни пароля (у AD або у організаційному порталі).

5. Велика кількість груп користувача

Користувач у 500+ групах AD. LDAP-запит «знайти всі групи цього користувача» повертає велику відповідь, що повільно. Рішення: використовувати tokenGroups атрибут (швидший, повертає SID-и груп) або обмежити запит конкретними групами з префіксом «UBD-».

Контроль вилучених облікових записів

Найважливіше з безпекової точки зору: коли користувач звільнений, його доступ до UBD має зникнути швидко. Стратегії:

  • Disable облікового запису у AD → UBD це бачить при наступній синхронізації (5 хв).
  • Видалення облікового запису у AD → те саме.
  • Час: типово 5-15 хвилин від звільнення до повного відключення.
  • Для критичних випадків (наприклад, звільнення з конфліктом) — ручне відключення у UBD одразу + потім AD.

Аудит: окремий звіт «користувачі, активні у UBD, але неактивні у AD» — повинен завжди бути порожнім.

[ ПРАКТИЧНА РЕАЛІЗАЦІЯ ]
Як UBD спрощує AD-інтеграцію

UBD має готові коннектори до Active Directory з графічним налаштуванням: майстер вводить параметри LDAP-з’єднання, обирає Base DN з дерева, тестує bind на льоту, мапить AD-групи на UBD-ролі візуально. Підтримуються всі описані сценарії синхронізації. Сертифікати TLS додаються через інтерфейс адміністратора.

UnityBaseDefense — технічна довідка →

Мітки