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

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

Интеграция с Active Directory позволяет связать корпоративный каталог сотрудников с существующей инфраструктурой организации.

При этом важно разделять задачи двух систем.

Active Directory и справочник решают разные задачи

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

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

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

Например:

Active Directory

→ учётная запись

→ группа безопасности

→ авторизация

Справочник

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

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

→ телефон

→ кабинет

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

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

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

Набор доступных атрибутов зависит от настройки каталога.

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

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

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

Не все данные должны храниться в Active Directory

В организации часть информации может находиться в других системах.

Например:

Active Directory

→ учётная запись

→ рабочая почта

1С

→ должность

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

АТС

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

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

→ кабинет

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

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

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

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

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

Справочник периодически получает данные и обновляет карточки сотрудников.

Например:

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

Ручное создание карточки при этом не требуется.

Active Directory как источник авторизации

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

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

Система проверяет их через существующую инфраструктуру организации.

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

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

Авторизация и синхронизация — разные задачи

Эти два сценария часто объединяют, хотя технически они различаются.

Авторизация

Определяет, кто пытается войти в систему.

Синхронизация

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

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

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

Логин кажется удобным идентификатором, но не всегда является неизменным.

Например, при изменении фамилии пользователя логин может измениться в соответствии с правилами организации.

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

Уникальный идентификатор пользователя

В Active Directory для идентификации объектов используются собственные идентификаторы.

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

Например:

objectGUID;
distinguishedName;
sAMAccountName;
userPrincipalName.

Конкретный вариант необходимо выбирать с учётом того, как устроена инфраструктура организации.

Почему distinguishedName не всегда подходит

distinguishedName содержит положение объекта в структуре каталога.

Например:

CN=Ivanov Ivan,OU=Employees,DC=company,DC=local

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

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

Изменение подразделения

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

В Active Directory изменяется соответствующий атрибут.

При следующей синхронизации справочник получает новое значение.

Например:

было:

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

стало:

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

Карточка сотрудника при этом не создаётся заново.

Изменяется существующая запись.

Изменение ФИО

ФИО также может измениться.

Например:

Иванова Анна Сергеевна

становится:

Петрова Анна Сергеевна

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

Это ещё один аргумент в пользу использования идентификатора вместо ФИО.

Увольнение сотрудника

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

Возможны разные варианты:

скрыть сотрудника;
перевести его в архив;
пометить как неактивного;
удалить после определённого периода.

Конкретное правило зависит от требований организации.

Отключённая учётная запись

В Active Directory пользователь может оставаться в каталоге, но иметь отключённую учётную запись.

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

Например:

Учётная запись отключена

→ сотрудник становится неактивным в справочнике.

Но это правило нельзя применять автоматически без учёта процессов конкретной организации.

Организационные единицы Active Directory

Active Directory может содержать структуру OU:

Employees
├── Management
├── Sales
├── IT
└── Finance

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

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

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

Почему OU не всегда равны подразделениям

Например, пользователи одного отдела могут быть распределены по нескольким OU из-за требований безопасности.

В результате:

Структура Active Directory

может не совпадать с:

Организационной структурой предприятия

Справочник должен учитывать эту разницу.

Подразделение как отдельный объект

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

Тогда сотрудник может иметь связь:

Сотрудник
    ↓
Подразделение
    ↓
Родительское подразделение

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

Несколько доменов

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

Например:

corp.company.local
branch.company.local

Сотрудники разных доменов при этом могут входить в одну организационную структуру.

Интеграция должна учитывать возможность существования нескольких источников.

Несколько лесов Active Directory

Ещё более сложная ситуация возникает при наличии нескольких лесов.

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

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

Несколько источников данных

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

Например:

Active Directory

→ учётная запись

1С

→ должность

АТС

→ телефон

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

→ итоговая карточка

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

Кто является владельцем данных

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

Например:

Данные	Источник
ФИО	1С
Должность	1С
Подразделение	1С
Логин	Active Directory
Email	Active Directory
Телефон	АТС
Кабинет	система помещений

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

Что делать при конфликте данных

Предположим, Active Directory содержит один номер телефона:

1234

а АТС сообщает:

5678

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

Если владельцем телефонных данных является АТС, значение из Active Directory не должно его перезаписывать.

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

Самый простой вариант интеграции — периодическая загрузка изменений.

Например:

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

Для многих организаций этого достаточно.

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

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

При полной синхронизации система получает весь набор пользователей.

Например:

Active Directory
        ↓
1248 пользователей
        ↓
Справочник

Система сравнивает полученные данные с текущим состоянием.

Преимущество такого подхода — относительная простота.

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

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

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

Например:

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

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

Ошибки синхронизации

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

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

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

Что делать с ошибочной записью

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

Вместо автоматического удаления карточки лучше сохранить ошибку в журнале.

Например:

Сотрудник: Иванов Иван Иванович

Ошибка: подразделение D002 не найдено

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

Логирование синхронизации

Для контроля работы интеграции полезно сохранять статистику.

Например:

22.08.2026 02:00

Получено пользователей: 1248
Добавлено: 12
Изменено: 34
Без изменений: 1198
Архивировано: 4
Ошибок: 2

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

Права доступа к Active Directory

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

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

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

Сервисная учётная запись

Для интеграции может использоваться отдельная учётная запись.

Например:

svc_orgnavigator

Она применяется исключительно для обмена между системами.

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

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

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

Кроме того, становится сложнее определить, какие действия были выполнены самой интеграцией, а какие — администратором.

Отдельная сервисная учётная запись упрощает контроль и аудит.

Безопасность соединения

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

Важно контролировать:

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

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

Active Directory и персональные данные

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

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

Нет необходимости копировать в пользовательский каталог все доступные атрибуты Active Directory.

Минимальный набор данных

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

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

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

Active Directory не должен становиться единственным источником всего

Иногда возникает желание получить из AD абсолютно все данные о сотруднике.

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

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

Лучше отделять техническую структуру источника от пользовательской модели справочника.

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

Перед началом работ желательно определить:

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

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

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

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

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

Итог

Интеграция с Active Directory может существенно упростить внедрение внутреннего справочника сотрудников.

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

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

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