Синхронизация пользователей с Active Directory (AD LDAP / OpenLDAP): как устроена
UnSpot умеет создавать и обновлять карточки сотрудников по данным локального каталога — Active Directory или OpenLDAP. Эта статья описывает, как устроен обмен: кто его инициирует, что именно уходит из каталога в UnSpot и по какому каналу, где хранятся учётные данные подключения и что за пределы каталога не выходит. Она адресована службе информационной безопасности, которая согласовывает использование интеграции. Как подключить и настроить синхронизацию, описано в статье «Настройка синхронизации с Active Directory (AD LDAP / OpenLDAP)».
Что делает эта синхронизация
Синхронизация односторонняя: данные переносятся из каталога в UnSpot, изменения в UnSpot обратно в каталог не записываются. Подключение выполняется в разделе Настройка → Интеграции → Синхронизации — карточка AD LDAP для Active Directory и карточка OpenLDAP для OpenLDAP и совместимых каталогов. Настраивать интеграции могут роли Владелец и Администратор интеграций.
Ключевое отличие этого способа от синхронизации через промежуточную службу: соединение к каталогу открывает облако UnSpot. Каталог не изолирован от внешней сети — контроллер домена должен быть доступен для входящих подключений со стороны UnSpot, а логин и пароль сервисной учётной записи хранятся на стороне UnSpot. Если такой доступ открывать нельзя, существует альтернатива, где приложение ставится в вашем контуре и обращается наружу само: «Синхронизация из on-premise AD (LDAP-SCIM): как устроена».
Кто к кому подключается

Одновременно к рабочему пространству может быть подключён только один способ синхронизации пользователей: AD LDAP, OpenLDAP, Entra ID или Google Workspace. Попытка подключить второй завершается ошибкой «Синхронизация пользователей уже подключена (используется другая служба каталогов)». Исключение — провижининг по SCIM: он живёт отдельно и может работать одновременно с любым из этих способов.
Как проходит один цикл

Автоматическая синхронизация выполняется раз в сутки по расписанию платформы. Кроме этого администратор может запустить обмен вручную кнопкой «Обновить on-premise AD» (в карточке OpenLDAP она подписана «Обновить on-premise») — не чаще одного раза в час.
Порядок шагов
- Пользователи. UnSpot подключается к каталогу, читает записи от указанного DN с учётом фильтра администратора и приводит карточки сотрудников в соответствие с выборкой.
- Группы. Читаются объекты групп каталога и создаются или обновляются соответствующие группы UnSpot. Группа, пропавшая из выборки — удалённая в каталоге или отсечённая фильтром групп, — удаляется и из UnSpot целиком, вместе с её ролью в политиках бронирования и правах доступа.
- Вхождение пользователей в группы. Отдельным запросом читается атрибут
memberOf, и состав групп UnSpot приводится к тому, что в каталоге.
Фотографии сотрудников и дерево подразделений в суточный цикл не входят. Аватары обновляются отдельным заданием платформы, а организационная структура читается только в момент подключения интеграции и в момент, когда администратор включает отметку «Синхронизация орг. структуры». Ручной запуск кнопкой «Обновить on-premise AD» их тоже не затрагивает: после реорганизации в каталоге дерево подразделений в UnSpot само не обновится.
Как записи сопоставляются
- Главный ключ —
objectGUIDобъекта Active Directory (в OpenLDAP —uidNumber). Он записывается в UnSpot как внешний идентификатор карточки и опознаёт её в следующих циклах. - Если совпадения по идентификатору нет, запись ищется по адресу электронной почты — за счёт этого синхронизация подхватывает карточки, заведённые в UnSpot вручную, вместо создания дублей.
- Запись без заполненного
userPrincipalNameв синхронизацию не попадает вовсе. Для OpenLDAP обязательныuidNumberиmail: запись без любого из них пропускается, даже если основным атрибутом выбранuid. - Если у пользователя пусты
givenNameилиsn, имя и фамилия разбираются из атрибутаnameпо первому пробелу. В OpenLDAP вместо этого подставляется адрес электронной почты. - Учётные записи, отключённые в Active Directory, из выборки исключаются: UnSpot проверяет флаги
userAccountControl. В OpenLDAP аналогичной проверки нет — отключённые записи туда не попадают только фильтром администратора. - Признак «срок действия учётной записи истёк» (
accountExpires) не обрабатывается: истёкшая, но не отключённая учётная запись останется активной в UnSpot.
Что передаётся в UnSpot
Набор полей задаёт администратор отметками в блоке «Данные для синхронизации». Адрес электронной почты, имя и фамилия отмечены всегда, и снять их нельзя; остальные поля уходят в UnSpot, только если отмечены. Ниже — полный перечень того, что UnSpot запрашивает у каталога.
| Данные | Атрибут каталога | Когда передаются | Что появляется в UnSpot |
|---|---|---|---|
| Адрес электронной почты | userPrincipalName либо mail — атрибут выбирает администратор | всегда | Логин сотрудника. Если выбранный атрибут пуст или содержит не адрес, подставляется userPrincipalName |
| Имя | givenName, иначе name | всегда | Имя в карточке сотрудника |
| Фамилия | sn, иначе name | всегда | Фамилия в карточке сотрудника |
| Идентификатор записи | objectGUID | всегда | Служебное поле: внешний идентификатор карточки, по нему запись опознаётся в следующих циклах |
| Путь объекта в каталоге | distinguishedName | всегда | В карточку не пишется. Из компонентов OU= собирается путь подразделения — используется при переносе организационной структуры |
| Признак отключённой учётной записи | userAccountControl | всегда | Не передаётся. UnSpot использует его только для отбора записей |
| Подразделение | department | при отметке «Отдел» | Отдел в карточке сотрудника |
| Руководитель | manager — по ссылке дополнительным запросом читается запись руководителя и берётся его адрес почты | при отметке «Руководитель» | Руководитель в карточке. Передаётся адрес почты, а не ФИО |
| Телефон | telephoneNumber | при отметке «Телефон» | Телефон в карточке сотрудника |
| Должность | title | при отметке «Должность» | Должность в карточке. Значение длиннее 128 символов обрезается |
| Номер пропуска | numberPass | при отметке «NumberPass» | Номер пропуска в системе контроля доступа (СКУД). Это не стандартный атрибут схемы каталога — его нужно завести самостоятельно |
| Фотография | thumbnailPhoto | при отметке «Аватар пользователя» | Аватар сотрудника. Уходит отдельным заданием, не в общем цикле |
| Название и идентификатор группы | name и objectGUID группы | при отметке «Группы» | Группа в UnSpot |
| Состав групп | memberOf пользователя | при отметке «Группы» | Участники группы UnSpot |
| Подразделения | name, description, managedBy объектов organizationalUnit | при отметке «Синхронизация орг. структуры» | Дерево подразделений, описание подразделения и адрес почты его руководителя |
В терминах персональных данных из каталога уходят: фамилия и имя, рабочий адрес электронной почты, рабочий телефон, должность, подразделение, номер пропуска СКУД, фотография сотрудника и адрес почты его руководителя — и только те из них, что отмечены в настройках. Табельный номер, дата рождения, домашний адрес и другие кадровые сведения UnSpot не запрашивает.
Что не передаётся
- Пароли и их хеши. UnSpot запрашивает у каталога строго перечисленный набор атрибутов, пароли в него не входят. Пароль для входа в UnSpot генерируется случайным образом на стороне UnSpot.
- Данные из UnSpot обратно в каталог. Обратной записи нет: UnSpot не создаёт, не изменяет и не удаляет объекты каталога — ему достаточно доступа на чтение.
- Брони, расписание и действия сотрудников. Из UnSpot в каталог не уходит ничего.
- Входящие подключения от каталога. UnSpot не принимает соединений от контроллера домена и не открывает для него порт: обмен всегда начинает UnSpot.
- Остальное содержимое каталога. Атрибуты, не перечисленные в таблице выше, не запрашиваются.
Одна оговорка, важная при выдаче прав. Для объектов групп и подразделений перечень возвращаемых атрибутов не ограничивается — UnSpot читает эти объекты целиком, включая полные списки участников. То же верно для записей руководителей в Active Directory, которые читаются по ссылке manager. В OpenLDAP иначе: запрос руководителей ограничен тем же набором атрибутов, что и основная выборка пользователей.
Направление и инициатор обмена
Все соединения инициирует облако UnSpot. Каталог никогда не обращается в UnSpot, поэтому исходящие правила на межсетевом экране для этой интеграции не нужны — нужны входящие.
| Что делает UnSpot | Куда идёт запрос | Когда |
|---|---|---|
| Подключается и проходит аутентификацию под сервисной учётной записью | LDAP или LDAPS к контроллеру домена в вашей сети | в начале каждого обращения к каталогу |
| Читает пользователей от указанного DN | то же соединение | раз в сутки и при ручном запуске |
| Читает группы и состав групп | то же соединение | раз в сутки и при ручном запуске |
| Читает подразделения | то же соединение | при подключении и при включении отметки «Синхронизация орг. структуры» |
| Читает фотографии сотрудников | отдельное подключение на каждого сотрудника | сразу при подключении и при включении отметки «Аватар пользователя», дальше — отдельным заданием платформы |
Обратный поток ограничен ответами каталога на эти запросы. Отдельно отметим поведение при переносе аватаров: задание не переиспользует одно соединение, а подключается к каталогу и проходит аутентификацию заново для каждого сотрудника. На каталоге с тысячей учётных записей это тысяча подключений за одно задание — это стоит учесть при настройке порогов на средствах защиты, иначе штатная работа интеграции будет выглядеть как перебор учётных данных.
Протокол, порты и шифрование
| Параметр | Значение |
|---|---|
| Протокол | LDAP версии 3. Схему задаёт администратор в поле «Хост»: ldap:// или ldaps:// |
| Порт | Значение по умолчанию в форме — 389, независимо от схемы. Для ldaps:// порт 636 нужно указать вручную |
| Шифрование канала | Только за счёт ldaps:// (неявный TLS). StartTLS не поддерживается |
| Аутентификация | Простая (simple bind): логин и пароль передаются в каталог при каждом подключении. Kerberos, NTLM и SASL не используются |
| Проверка сертификата сервера | Не выполняется — см. предупреждение ниже |
| LDAP referrals | Отключены |
| Ограничение на число возвращаемых записей | Со стороны UnSpot не задаётся; постраничное чтение не реализовано — действует серверное ограничение каталога |
Проверка подлинности сервера каталога отключена, и включить её настройкой нельзя. UnSpot принудительно выставляет режим, при котором сертификат сервера не проверяется. Практическое следствие: соединение по ldaps:// шифруется, но не подтверждает, что на другом конце действительно ваш контроллер домена — сертификат может быть самоподписанным, просроченным или выписанным на чужое имя, и UnSpot это не заметит. Компенсирующие меры на вашей стороне: ограничить входящие подключения на порт каталога списком адресов UnSpot (актуальный список запросите в поддержке), вынести трафик в выделенный сегмент или туннель и контролировать подмену маршрута средствами сети.
Второе следствие того же порядка: соединение по ldap:// идёт без шифрования, и логин с паролем сервисной учётной записи передаются по сети в открытом виде. Проверка префикса выполняется только в форме настройки — при обращении к внутреннему интерфейсу напрямую адрес без префикса будет принят и подключение пойдёт нешифрованным.
Где хранятся учётные данные
- Пароль сервисной учётной записи шифруется перед записью в базу данных рабочего пространства — AES-256-CBC со случайным вектором инициализации. Ключ шифрования задаётся на уровне инсталляции UnSpot.
- Логин сервисной учётной записи не шифруется и хранится в базе как есть.
- Пароль не отдаётся ни одним интерфейсом UnSpot — ни в форме настройки, ни в ответе служебного запроса состояния интеграции. Ввести его повторно можно, прочитать — нет.
- Логин виден в ответе служебного запроса состояния интеграции, и этот запрос, в отличие от остальных операций с синхронизацией, не требует роли администратора интеграций — достаточно быть авторизованным пользователем рабочего пространства.
Ещё одно место, где могут оказаться персональные данные: прикладной журнал. Если карточка сотрудника не прошла проверку при записи, весь набор синхронизированных данных по этому сотруднику — адрес почты, ФИО, телефон, должность, отдел, номер пропуска — записывается в журнал приложения. Журналы доступны службе эксплуатации UnSpot, а не администратору рабочего пространства.
Что кэшируется и что остаётся в UnSpot
| Что | Где | Сколько живёт |
|---|---|---|
| Соответствие «идентификатор в каталоге → карточка UnSpot» | служебная таблица базы данных рабочего пространства | пока подключена синхронизация. Удаляется при отключении и при переподключении |
| Соответствие «идентификатор группы → группа UnSpot» | служебная таблица | то же; дополнительно удаляется при снятии отметки «Группы» |
| Метка времени следующего доступного ручного запуска | кэш платформы | 1 час, истекает сама |
| Выборка пользователей и групп текущего цикла | только в памяти процесса | до конца обработки задания, на диск не пишется |
| Фотографии сотрудников | файловое хранилище UnSpot; при обработке — временный каталог | пока есть карточка. Временный файл удаляется после обработки |
Постоянного кэша самой выборки из каталога нет: каждый цикл читает каталог заново. Отключение синхронизации не удаляет карточки сотрудников — они остаются в UnSpot, но связь с записями каталога стирается, и при повторном подключении объекты сопоставляются заново по адресам электронной почты.
Требования к сети и правам
- Доступность каталога: контроллер домена должен принимать входящие подключения с адресов UnSpot на порт LDAP или LDAPS.
- Права сервисной учётной записи: только чтение. Нужен доступ на чтение объектов пользователей (включая
userAccountControlиobjectGUID), объектов групп и объектов подразделений, а при переносе аватаров — атрибутаthumbnailPhoto. Права на запись не требуются ни для одной операции. - Контейнер поиска: DN контейнера обязателен — искать «от корня каталога» форма не позволяет. Всё, что находится вне указанного DN, в выборку не попадает.
- Ограничение выборки: фильтр LDAP задаёт администратор. При пустом фильтре синхронизируются все подходящие объекты внутри указанного DN.
Что происходит, когда сотрудник исчезает из каталога
Сразу отделим случай, когда каталог просто недоступен или не отвечает: это не «исчезновение», и ничего разрушительного не происходит — цикл прерывается до сопоставления, никто не архивируется, а обмен повторится по расписанию. Если же каталог отвечает ошибкой аутентификации, подключение помечается недействительным: на карточке появляется сообщение о недействительной учётной записи и кнопка «Переподключить», и синхронизация останавливается, пока администратор не проверит учётные данные.
Это самая заметная для эксплуатации часть механики, и её стоит разобрать до подключения. Если сотрудник перестал попадать в выборку — его удалили из каталога, отключили его учётную запись или он вышел за границы фильтра, — карточка в UnSpot архивируется. Архивация означает следующее:
- отменяются все бронирования сотрудника;
- удаляются его сессии и токены доступа;
- удаляются подключённые им календари;
- снимаются бронирования ячеек хранения;
- снимаются закреплённое рабочее место и парковочное место;
- снимаются права делегата на переговорные комнаты;
- сотрудник исключается из всех групп, команд и списка избранных мест;
- сама запись сотрудника из базы не удаляется — она помечается архивной, и при возвращении в каталог карточка восстанавливается.
Отсюда — риск, который нужно учитывать при согласовании. Со стороны UnSpot ограничение на число возвращаемых записей не задаётся, а постраничное чтение не реализовано. Если каталог отдаст выборку не полностью — например, сработает серверное ограничение на число записей в ответе, — недостающие сотрудники будут выглядеть как исчезнувшие из каталога, и их карточки заархивируются вместе с отменой всех броней. Проверьте политику ограничения размера ответа на контроллере домена и держите фильтр таким, чтобы выборка в него укладывалась.
Чем OpenLDAP отличается от Active Directory
Форма настройки у карточек одинаковая, но читают каталог они по-разному. Различия, которые имеют значение для согласования и для эксплуатации:
| Что | AD LDAP | OpenLDAP |
|---|---|---|
| Класс объектов пользователей | objectClass=user | objectClass=inetOrgPerson |
| Класс объектов групп | objectClass=group | objectClass=posixGroup |
| Внешний идентификатор | objectGUID | uidNumber |
| Обязательные атрибуты записи | userPrincipalName | uidNumber и mail |
| Значение «основной атрибут» в форме | userPrincipalName — читается именно он | подписано userName, фактически читается uid |
| Атрибут подразделения | department | departmentNumber |
| Атрибут фотографии | thumbnailPhoto | jpegPhoto |
| Состав групп | по memberOf пользователя | по memberUid группы |
| Отсев отключённых учётных записей | есть, по userAccountControl | отсутствует |
| Отсев служебных групп | есть | отсутствует |
| Название подразделения | атрибут name | атрибут ou |
| Руководитель подразделения | переносится из managedBy | не переносится |
| Если пусты имя и фамилия | разбираются из name | подставляется адрес электронной почты |
Что учесть при согласовании
- Каталог доступен извне. Соединение инициирует облако, поэтому контроллер домена открыт для входящих подключений UnSpot, а не изолирован в контуре.
- Подлинность сервера не проверяется. Шифрование по
ldaps://есть, аутентификации сервера нет, отключить это поведение нельзя — нужны компенсирующие меры на уровне сети. - Учётные данные каталога хранятся у UnSpot. Пароль шифрован, логин — нет; логин виден в служебном ответе любому авторизованному пользователю рабочего пространства.
- Неполная выборка приводит к архивации сотрудников с отменой их броней и сессий.
- Персональные данные могут попасть в прикладной журнал при ошибке записи карточки.
- Ограничение частоты ручного запуска относится к кнопке в консоли, а не к механизму синхронизации: у внутреннего интерфейса есть операция запуска обмена без часового ограничения, доступная роли администратора интеграций.
Если какой-то из этих пунктов не проходит согласование, рассмотрите схему с промежуточной службой: она ставится в вашем контуре, читает каталог локально и передаёт данные в UnSpot сама, поэтому входящих подключений к каталогу не требует и учётные данные каталога наружу не отдаёт — «Синхронизация из on-premise AD (LDAP-SCIM): как устроена».