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 має готові коннектори до Active Directory з графічним налаштуванням: майстер вводить параметри LDAP-з'єднання, обирає Base DN з дерева, тестує bind на льоту, мапить AD-групи на UBD-ролі візуально. Підтримуються всі описані сценарії синхронізації. Сертифікати TLS додаються через інтерфейс адміністратора.
UnityBaseDefense — технічна довідка →