Во многих организациях Active Directory уже является частью основной IT-инфраструктуры.

В каталоге хранятся учётные записи сотрудников, логины, группы безопасности и другие сведения, необходимые для работы корпоративных систем.

При этом Active Directory не всегда является удобным инструментом именно для поиска сотрудников.

Пользователю может быть нужно узнать телефон коллеги, его должность, подразделение или кабинет. Для таких задач удобнее специализированный внутренний справочник.

Поэтому Active Directory и корпоративный каталог могут дополнять друг друга.

Что такое Active Directory в контексте справочника

Active Directory обычно используется для управления учётными записями и доступом к корпоративным ресурсам.

В ней могут храниться:

имя пользователя;
логин;
электронная почта;
подразделение;
должность;
телефон;
руководитель;
группы безопасности.

Набор атрибутов зависит от настроек конкретной организации.

Почему Active Directory недостаточно для справочника

Active Directory решает прежде всего задачи управления учётными записями и инфраструктурой.

Корпоративному справочнику могут потребоваться дополнительные возможности:

удобный поиск сотрудников;
дерево подразделений;
карточки сотрудников;
каталог помещений;
здания и кабинеты;
дополнительные рабочие контакты;
настройки видимости данных;
поиск по внутреннему телефону.

Поэтому использование Active Directory не обязательно означает отказ от отдельного справочника.

Какие данные можно получать из Active Directory

Для каталога могут быть полезны:

ФИО;
логин;
рабочая почта;
должность;
подразделение;
телефон;
руководитель;
статус учётной записи.

При этом не обязательно импортировать все атрибуты пользователя.

Лучше заранее определить минимальный набор данных, который действительно нужен справочнику.

Active Directory как источник данных

Один из вариантов архитектуры — использовать Active Directory как источник информации.

Например:

Active Directory

→ ФИО

→ email

→ логин

→ телефон

↓

Оргнавигатор

→ карточка сотрудника

→ поиск

→ организационная структура

В таком случае данные не приходится вводить повторно.

Active Directory как источник идентификатора

Одним из важных преимуществ Active Directory является наличие стабильных идентификаторов.

Для связи с сотрудником могут использоваться различные атрибуты.

Например:

objectGUID;
objectSid;
логин;
другой идентификатор, определённый организацией.

Конкретный вариант зависит от архитектуры и требований системы.

Почему логин не всегда идеален

Логин часто кажется очевидным идентификатором.

Например:

ivanov

Но логин может измениться.

Например, после изменения фамилии сотрудника организация может изменить имя учётной записи.

Поэтому при проектировании интеграции желательно учитывать более стабильный идентификатор объекта.

Связь с кадровой системой

Active Directory и кадровая система могут содержать данные об одном сотруднике.

Например:

Кадровая система

→ табельный номер 10452

Active Directory

→ objectGUID

АТС

→ phone_id = 7821

Справочник связывает эти идентификаторы с одной карточкой сотрудника.

Не стоит связывать системы по ФИО

ФИО может использоваться для предварительного сопоставления при миграции.

Но делать его основным механизмом автоматической синхронизации рискованно.

Причины очевидны:

одинаковые ФИО;
изменение фамилии;
разные форматы написания;
ошибки в исходных данных;
различия в транслитерации.

Стабильный идентификатор значительно надёжнее.

Синхронизация пользователей

Обмен с Active Directory может выполняться периодически.

Например:

каждые 15 минут;
каждый час;
несколько раз в сутки;
один раз в сутки.

Выбор зависит от того, насколько быстро изменения должны появляться в справочнике.

Что происходит при создании учётной записи

Предположим, в Active Directory появился новый пользователь.

Система синхронизации получает его данные.

Если соответствующего сотрудника ещё нет в справочнике, может быть создана новая карточка.

Однако автоматическое создание не всегда должно происходить сразу.

Иногда требуется дополнительная проверка.

Почему новая учётная запись не всегда означает нового сотрудника

В организации могут существовать:

технические учётные записи;
сервисные пользователи;
временные аккаунты;
общие учётные записи;
учётные записи внешних пользователей.

Не все они являются сотрудниками.

Поэтому перед импортом необходимо определить критерии отбора.

Фильтрация пользователей

Например, из Active Directory можно исключать:

сервисные учётные записи;
отключённые технические аккаунты;
системные объекты;
тестовые записи.

В каталог должны попадать только те пользователи, которые действительно относятся к сотрудникам организации.

Что делать с отключённой учётной записью

Отключение учётной записи может быть признаком увольнения или временного прекращения доступа.

Но это не всегда одно и то же.

Поэтому справочник не должен автоматически трактовать каждую отключённую учётную запись как окончательное увольнение.

Правила необходимо определить с учётом кадровой системы.

Кадровая система и Active Directory должны дополнять друг друга

Если кадровая система является источником кадровой информации, а Active Directory — источником учётных записей, обязанности можно разделить.

Например:

Данные	Источник
ФИО	кадровая система
Должность	кадровая система
Подразделение	кадровая система
Статус сотрудника	кадровая система
Логин	Active Directory
Email	Active Directory
Учётная запись	Active Directory

Такой подход позволяет каждой системе оставаться владельцем своей информации.

Что делать при расхождении данных

Предположим, в кадровой системе указано:

Отдел закупок

А в Active Directory:

Отдел снабжения

Нельзя автоматически считать одно из значений правильным только потому, что оно получено последним.

Для каждого атрибута должен быть определён источник истины.

Если подразделение принадлежит кадровой системе, используется её значение.

Электронная почта

Рабочий email часто удобно получать из Active Directory.

Например:

ivanov@company.local

При изменении адреса каталог может автоматически получить новое значение.

Это особенно полезно, если почтовая система и Active Directory работают совместно.

Телефон в Active Directory

В некоторых организациях рабочий телефон также хранится в атрибутах Active Directory.

В этом случае его можно использовать как источник для справочника.

Однако если актуальные номера управляются АТС, лучше считать именно АТС владельцем телефонных данных.

Несколько источников для одной карточки

На практике может использоваться следующая схема:

Кадровая система

→ ФИО и должность

Active Directory

→ логин и email

АТС

→ внутренний телефон

Система помещений

→ кабинет

Оргнавигатор

→ единая карточка сотрудника

Пользователь при этом видит все необходимые сведения в одном месте.

Active Directory и права доступа

Active Directory может использоваться не только как источник данных.

В некоторых сценариях она позволяет организовать вход пользователей в корпоративную систему.

Например, сотрудник использует свою корпоративную учётную запись для доступа к справочнику.

Это избавляет от необходимости создавать отдельный пароль для каждого пользователя.

Авторизация и данные каталога — разные задачи

Важно разделять две функции.

Active Directory

→ подтверждает личность пользователя.

Справочник

→ определяет, какие сведения о сотрудниках доступны этому пользователю.

Например, успешный вход через корпоративную учётную запись ещё не означает, что сотрудник должен видеть все поля карточек.

Ограничение видимости данных

Внутренний справочник может использовать собственные правила доступа.

Например:

Все сотрудники

→ ФИО

→ подразделение

→ рабочий телефон

Руководители

→ дополнительные контакты

Администраторы

→ служебные данные

Таким образом, Active Directory может отвечать за аутентификацию, а справочник — за доступ к информации.

Группы Active Directory

Для управления правами могут использоваться группы.

Например:

ORG-Directory-Admins

или

ORG-Directory-Editors

Пользователь, входящий в соответствующую группу, получает определённую роль в справочнике.

Конкретная модель зависит от требований организации.

Ограничение редакторов

Особенно полезным может быть разграничение прав редактирования.

Например, сотрудники отдела кадров могут изменять определённые данные.

Ответственные за конкретное подразделение могут редактировать только его сотрудников.

Администратор имеет полный доступ.

Это позволяет не предоставлять одинаковые права всем пользователям.

Что делать при увольнении

При увольнении сотрудника может произойти несколько событий:

кадровая система изменяет статус сотрудника;
Active Directory блокирует учётную запись;
АТС освобождает телефон;
справочник переводит карточку в архив.

Эти операции могут происходить не одновременно.

Поэтому необходимо определить, какая система является основной для принятия решения об увольнении.

Что делать при переводе

При переводе сотрудника кадровая система может изменить подразделение.

Active Directory может обновить соответствующие группы.

Справочник должен получить новое подразделение и сохранить связь с той же карточкой сотрудника.

Такой сценарий хорошо показывает необходимость стабильного идентификатора.

Организационные подразделения

Active Directory может содержать организационные единицы и группы.

Но они не всегда полностью совпадают с реальной организационной структурой.

Например, OU может быть создана для технических целей.

Поэтому нельзя автоматически считать каждую OU полноценным подразделением организации.

Почему OU и подразделение — не одно и то же

Организационная структура отвечает на вопрос:

К какому подразделению относится сотрудник?

OU отвечает на вопрос:

Как организованы объекты внутри каталога Active Directory?

Эти структуры могут совпадать, но не обязаны.

Для корпоративного справочника необходимо использовать ту модель, которая соответствует реальной структуре организации.

Контроль качества данных

Перед синхронизацией полезно проверять:

наличие идентификатора;
корректность email;
наличие подразделения;
отсутствие дублей;
соответствие сотрудника кадровой системе;
статус учётной записи.

Ошибки лучше фиксировать в журнале, чем автоматически создавать неправильные карточки.

Что делать при недоступности Active Directory

Временная недоступность каталога не должна приводить к исчезновению сотрудников из справочника.

Можно продолжать использовать последние успешно загруженные данные.

После восстановления соединения синхронизация выполняется повторно.

Полная синхронизация

При полном обмене система получает всех подходящих пользователей Active Directory.

Например:

Пользователей: 4200

Справочник сравнивает их с существующими карточками.

Такой вариант проще реализовать, но при больших объёмах может потреблять больше ресурсов.

Инкрементальная синхронизация

Другой вариант — передавать только изменившиеся объекты.

Например:

Добавлено: 14

Изменено: 31

Отключено: 6

Это позволяет сократить объём обработки.

Для крупных каталогов такой подход может быть предпочтительным.

Журнал синхронизации

Полезно сохранять результат каждой операции.

Например:

19.08.2026 02:00

Получено пользователей: 4218
Добавлено: 14
Изменено: 31
Архивировано: 6
Без изменений: 4164
Ошибок: 3

Так администратор может быстро оценить состояние обмена.

Контроль аномальных изменений

Предположим, обычно за сутки изменяется несколько десятков пользователей.

Внезапно синхронизация сообщает:

Изменено: 3800

Это может быть результатом ошибки настройки или массового изменения атрибутов.

Перед применением таких изменений желательно иметь механизм контроля аномалий.

Безопасность подключения

Учётная запись, используемая для чтения Active Directory, должна иметь минимально необходимые права.

Если справочнику требуется только получение данных, не следует предоставлять ему возможность изменять объекты каталога.

Это уменьшает последствия возможной ошибки или компрометации системы.

Локальная инфраструктура

Для организаций, использующих внутреннюю сеть, Active Directory и справочник могут работать внутри одного корпоративного контура.

Например:

Active Directory

↓

Оргнавигатор

↓

Пользователи внутренней сети

Внешний интернет при этом не требуется для получения основных данных.

Когда интеграция особенно полезна

Связь с Active Directory может быть особенно полезна, если:

в организации много сотрудников;
учётные записи уже централизованы;
данные регулярно меняются;
требуется единый вход;
справочник работает во внутренней сети;
необходимо автоматизировать обновление контактов.

Что проверить перед интеграцией

Перед подключением стоит определить:

какие атрибуты Active Directory используются;
какие пользователи должны попадать в справочник;
какой идентификатор будет основным;
какая система является источником кадровых данных;
какие поля можно редактировать вручную;
как обрабатываются отключённые аккаунты;
как выполняется синхронизация;
как журналируются ошибки.

Оргнавигатор и Active Directory

Оргнавигатор может использовать Active Directory как один из источников информации о сотрудниках и одновременно учитывать корпоративные учётные записи при организации доступа к системе.

При этом кадровые данные, телефонные номера и сведения о помещениях могут поступать из других источников.

Такой подход позволяет сохранить существующую инфраструктуру и объединить необходимые сведения в едином внутреннем каталоге.

Итог

Active Directory уже содержит значительный объём информации, который может быть полезен внутреннему справочнику сотрудников.

Однако каталог пользователей и справочник организации решают разные задачи. Active Directory управляет учётными записями и доступом, а специализированный каталог предоставляет удобный поиск сотрудников, организационную структуру, контакты и помещения.

Наиболее эффективный подход заключается в том, чтобы связать системы, определить владельцев данных и использовать стабильные идентификаторы.

Тогда пользователю не приходится искать информацию в нескольких корпоративных системах, а актуальность основных сведений поддерживается автоматически.