Мы подключили лабораторный Active Directory к GLPI 11: 7 пользователей импортированы за 1,4 секунды, каждый получил правильный профиль по группе AD и вход с сетевым паролем. До этого момента всё шло как ожидалось. Проблема возникла, когда мы отключили сотрудника в AD: в GLPI он остался активным, с тем же профилем. И последующее изменение настроек не помогло, потому что GLPI применяет правило отключения только в первый раз, когда замечает уход.
Используете Microsoft Entra ID (Azure AD) и хотите единый вход в браузере? Смотрите SSO с Microsoft Entra ID в GLPI. Эта статья посвящена локальному AD через LDAP.
Что даёт интеграция с AD
- Вход с сетевым паролем: пользователь входит в GLPI с тем же логином и паролем, что и в Windows. Пароль никогда не хранится в GLPI.
- Импорт данных: имя, фамилия, e-mail, телефон, должность и другие поля берутся из AD.
- Профиль по группе: правила авторизации назначают профиль и организацию в зависимости от группы AD (специалист, руководитель, пользователь).
- Синхронизация: изменения в AD, например смена телефона, должности или увольнение, попадают в GLPI при плановой синхронизации.
Лаборатория
Мы развернули контроллер домена Samba (совместимый с Active Directory) с доменом ACME.TEST, вымышленной компанией Acme, тремя группами (GLPI-Tecnicos, GLPI-Gestores, GLPI-Usuarios) и восемью пользователями: семь активных и один отключённый в OU уволенных. С другой стороны — тестовый GLPI 11.0.7.
Шаг 1: каталог LDAP
В Настройки > Аутентификация > Каталоги LDAP:
| Поле | Что мы использовали | Почему |
|---|---|---|
| Сервер и порт | контроллер домена, 389 (636 с LDAPS) | В продакшене предпочтительны LDAPS или StartTLS |
| BaseDN | OU=Acme,DC=acme,DC=test |
Начинайте с OU сотрудников, а не с корня домена |
| RootDN и пароль | сервисная учётная запись только для чтения | Никогда не учётная запись администратора |
| Фильтр подключения | (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) |
Только люди и только активные учётные записи |
| Поле логина | samaccountname |
Короткий логин Windows |
| Поле синхронизации | objectguid |
Не меняется, если пользователь сменит имя или OU |
| Группы | тип поиска «В пользователях», атрибут memberof |
Чтобы использовать группу AD в правилах |
Кнопка Проверить проверяет подключение до импорта чего-либо.
Шаг 2: профиль по группе AD
В Администрирование > Правила > Правила назначения прав пользователю — по одному правилу на группу:
Если пользователь пришёл из этого каталога и memberOf содержит |
Получает профиль | В организации |
|---|---|---|
CN=GLPI-Tecnicos, |
Technician | организация компании |
CN=GLPI-Gestores, |
Supervisor | организация компании |
CN=GLPI-Usuarios, |
Self-Service | организация компании |
Права, назначенные правилом, динамические: если человек выйдет из группы в AD, профиль снимется при следующей синхронизации.
Шаг 3: импорт и синхронизация
Через интерфейс (Импорт новых пользователей) или из командной строки — именно её стоит использовать для планирования:
php bin/console ldap:synchronize_users --ldap-server-id=1 --deleted-user-strategy=1,0,1
В лаборатории импорт загрузил 7 активных пользователей за 1,4 секунды, а отключённый был отсеян фильтром. Имя, e-mail и телефон пришли из AD, и каждый получил профиль своей группы. Вход с паролем AD сработал, а с неверным паролем был отклонён.
Что произошло, когда мы отключили сотрудника
Мы отключили пользователя в AD и запустили синхронизацию, сначала с настройками по умолчанию.
| Тест | Результат в GLPI |
|---|---|
| Отключён в AD, синхронизация по умолчанию | GLPI обнаруживает уход, но ничего не делает: пользователь активен, профиль тот же |
| Тот же пользователь, следующая синхронизация с «отключить» | Ничего не меняется: он уже был помечен как удалённый из LDAP |
| Другой отключённый пользователь, «отключить» задано уже при первой синхронизации | Пользователь отключён, динамические профили сняты |
| Пользователь повторно активирован в AD, синхронизация с «включить» | Снова становится активным |
Два вывода:
- По умолчанию GLPI ничего не делает с теми, кто ушёл из AD (стратегия «0,0,0»). Бывший сотрудник сохраняет активную учётную запись в GLPI, пока кто-нибудь не заметит.
- Стратегия применяется в момент, когда GLPI обнаруживает уход. Если первая синхронизация прошла с настройками по умолчанию, последующее изменение конфигурации не затронет уже помеченных. Таких пользователей нужно обрабатывать вручную.
Настройте действие для пользователя, удалённого из LDAP, до первой синхронизации (в Настройки > Аутентификация или параметром --deleted-user-strategy в команде). Рекомендуемая нами комбинация — «1,0,1»: отключить учётную запись, сохранить группы (для истории) и снять динамические права.
Для возврата стратегия восстановления «3» снова включает учётную запись, когда человека повторно активируют в AD.
Деталь о профиле по умолчанию
Все импортированные пользователи получили также профиль по умолчанию GLPI (в нашем случае Self-Service) в дополнение к профилю из правила. Специалистам это не мешает, но он виден при переключении профиля. Если это нежелательно, проверьте, какой профиль в GLPI задан по умолчанию, перед импортом.
Чек-лист
- Сервисная учётная запись только для чтения в качестве RootDN.
- LDAPS или StartTLS в продакшене.
- BaseDN в OU сотрудников и фильтр, исключающий отключённые учётные записи.
objectguidв качестве поля синхронизации.- Правила авторизации по группам AD с заданной организацией.
- Действие для пользователя, удалённого из LDAP, настроено до первой синхронизации («1,0,1»).
- Плановая синхронизация (cron) с
ldap:synchronize_users, как минимум ежедневно. - Тест на вымышленном пользователе: создать, сменить группу, отключить и повторно активировать в AD, проверяя GLPI на каждом шаге.
Нужна помощь с интеграцией или аудитом доступа? Свяжитесь с командой. Чтобы разобраться в профилях и правах, смотрите профили и права в GLPI.
Тест NexTool от 4 октября 2026 г.: контроллер домена Samba (совместимый с Active Directory) с вымышленными пользователями и тестовый GLPI 11.0.7. По завершении лаборатория была удалена. Поведение синхронизации проверено непосредственно в команде GLPI.
Комментарии
Комментарии к этой публикации загружаются с GitHub (giscus). При загрузке ваш браузер подключается к GitHub, который получает ваш IP-адрес и может сохранять собственные файлы cookie.
Чтобы загружать их автоматически, включите функциональные файлы cookie