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

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

На практике Active Directory и справочник сотрудников решают разные задачи. AD отвечает прежде всего за идентификацию и управление учётными записями, а справочник — за удобное представление информации о сотрудниках, подразделениях и помещениях.

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

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

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

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

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

Зачем связывать две системы

Если информация уже существует в Active Directory, нет смысла заставлять администратора вручную вводить её ещё раз.

Например, сотрудник создаётся в корпоративной инфраструктуре.

В AD уже появляются:

Иванов Иван Иванович

ivanov

ivanov@company.local

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

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

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

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

Например:

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

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

Авторизация через Active Directory

Один из наиболее полезных сценариев — использование AD для входа пользователей.

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

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

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

Что происходит при входе

Упрощённо процесс выглядит следующим образом:

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

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

Почему отдельные пароли неудобны

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

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

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

При централизованной авторизации часть этих задач уже решается существующей инфраструктурой.

Что происходит после увольнения

Рассмотрим типичный сценарий.

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

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

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

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

Пользователь и сотрудник — не одно и то же

Это важное архитектурное различие.

Сотрудник — объект справочника.

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

Большинство сотрудников могут только просматривать каталог.

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

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

Группы Active Directory

AD позволяет объединять пользователей в группы.

Например:

OrgNavigator-Users;
OrgNavigator-Editors;
OrgNavigator-Admins.

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

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

Права доступа через группы

Пример простой модели:

OrgNavigator-Users

→ просмотр.

OrgNavigator-Editors

→ просмотр и редактирование.

OrgNavigator-Admins

→ администрирование.

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

Подразделения в Active Directory

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

Например:

Компания

→ Департамент ИТ

→ Отдел инфраструктуры

→ Группа серверных систем

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

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

Почему структура AD может отличаться от оргструктуры

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

Организационная структура компании может иметь дополнительные сущности:

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

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

Синхронизация подразделений

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

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

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

Синхронизация сотрудников

Для сотрудника можно получать из AD:

ФИО;
логин;
email;
телефон;
должность;
подразделение.

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

Если телефон одновременно изменяется в АТС, две системы не должны конкурировать за одно и то же поле.

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

Для надёжной связи желательно использовать стабильный идентификатор объекта AD.

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

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

Изменение фамилии

Предположим, сотрудник Иванова Анна Сергеевна изменила фамилию.

В AD обновляется имя пользователя.

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

История сотрудника при этом не теряется.

Изменение должности

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

Но если кадровые данные являются источником 1С, должность логичнее получать именно оттуда.

Главное — заранее определить владельца каждого поля.

Что делать с телефонами

Телефон часто является проблемным полем.

Он может одновременно существовать:

в Active Directory;
в АТС;
в кадровой системе;
в самом справочнике.

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

Например:

АТС

→ рабочий внутренний номер.

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

Справочник

→ отображение результата пользователю.

Фотографии сотрудников

Active Directory может содержать фотографии пользователей.

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

Однако здесь важно учитывать:

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

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

Данные о помещениях

Active Directory обычно не является источником информации о кабинетах и зданиях.

Например, сотрудник может находиться:

Корпус №2

→ 3 этаж

→ кабинет 312.

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

Справочник как объединяющий слой

Один из наиболее практичных вариантов архитектуры — использовать справочник как единый пользовательский интерфейс.

Например:

1С

→ кадровые данные

Active Directory

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

АТС

→ телефон

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

→ кабинет

↓

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

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

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

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

Предположим, в 1С у сотрудника указан телефон 1234, а в AD — 5678.

Какое значение должен показывать справочник?

Ответ должен быть определён заранее.

Например:

Источником рабочего телефона является АТС.

Тогда значения из 1С и AD игнорируются для этого поля.

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

Active Directory и права редакторов

AD может использоваться не только для входа.

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

Например, членство в группе:

OrgNavigator-Editors

может предоставлять права редактора.

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

Изменение состава групп

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

Администратор AD добавляет пользователя в нужную группу.

После этого права в справочнике изменяются автоматически.

Когда сотрудник исключается из группы, соответствующий доступ также прекращается.

Работа в изолированной сети

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

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

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

Резервный контроллер домена

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

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

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

Что делать при временной недоступности AD

Не каждый сценарий требует постоянного обращения к Active Directory.

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

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

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

Безопасность интеграции

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

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

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

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

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

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

Типичная архитектура

Для организации среднего размера архитектура может выглядеть так:

Active Directory

→ пользователи и группы

1С

→ сотрудники и подразделения

АТС

→ телефоны

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

→ единый каталог

Пользователь

→ поиск и просмотр

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

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

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

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

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

Итог

Active Directory и корпоративный справочник не являются конкурентами.

AD отвечает прежде всего за учётные записи, а справочник — за удобное представление информации об организации и её сотрудниках.

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

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