Интеграция с каталогом и SSO: где начинаются и заканчиваются Entra ID и LDAP

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

Подключение к корпоративному каталогу это решает. Но «интеграция с каталогом» — не одна вещь, а две задачи, которые регулярно путают.

SSO подтверждает, каталог поставляет

Провести эту границу сразу — значит упростить все последующие решения.

SSO (SAML или OIDC) — задача аутентификации. Человек входит под корпоративной учётной записью, не держит отдельного пароля для интранета и теряет доступ в тот момент, когда эта учётная запись закрывается. Вопрос, на который отвечает SSO: «Действительно ли это тот человек, за кого он себя выдаёт?»

Сверка с каталогом — задача поставки данных. Она читает, кто работает, в каком подразделении и с какой должностью, и записывает это в профили интранета. Её вопрос другой: «Из кого сегодня состоит штат?»

Одно не заменяет другое. Если внедрить только SSO, вход станет удобнее, а каталог продолжит устаревать — потому что сотрудник, ни разу не входивший в систему, вообще не появится. Если внедрить только сверку, справочник останется актуальным, но каждый по-прежнему носит отдельный пароль. Зрелые установки используют оба механизма.

Сторона Entra ID

На стороне Microsoft Entra ID (прежнее название — Azure AD) настройка начинается с регистрации приложения. Интранет подключается к каталогу под собственной учётной записью через эту регистрацию; ничья личная учётная запись не используется.

Нужны три значения: идентификатор каталога (арендатора), идентификатор приложения (клиента) и клиентский секрет. Плюс разрешение: чтобы читать штат, приложению выдают User.Read.All, и эта выдача проходит через согласие администратора. Если шаг с согласием забыт, проверка соединения получает токен, но список пользователей возвращается пустым — поэтому добротная проверка не должна останавливаться на токене, ей следует действительно опросить конечную точку пользователей.

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

Сторона LDAP / Active Directory

Если в организации есть классический Active Directory, соединение идёт по LDAP. Здесь требуется другое: адрес сервера, учётная запись с правами чтения (bind DN) и точка, с которой начинается поиск (base DN).

Две детали определяют большинство внедрений. Первая — шифрованное соединение: без LDAPS или StartTLS корпоративные учётные данные идут по сети в открытом виде. Вторая — отсев отключённых учётных записей: в Active Directory записи уволившихся обычно не удаляют, а отключают. Это состояние хранится битом в атрибуте userAccountControl; если не добавить его в фильтр, каждый уволившийся попадёт в интранет как «действующий сотрудник» — то есть воспроизведётся ровно та проблема, которую вы собирались решить, только теперь автоматически.

Сначала показать, потом применить

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

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

Границы тоже стоит знать заранее. В Wepilot сверка не создаёт ни учётных записей, ни подразделений; она обновляет существующие профили. Причина — осторожность: сотни учётных записей, созданных из-за неверного фильтра, откатить куда труднее, чем поля профилей, записанные той же ошибкой. Полностью автоматический жизненный цикл учётных записей — приём, перевод и увольнение через SCIM — отдельная тема и в объём этой интеграции не входит.

Где хранятся секреты?

То, что несёт эта интеграция, — не обычная настройка, а доступ к вашему каталогу. Клиентский секрет и пароль LDAP не должны попадать в браузер никогда.

Правильный приём — держать эти записи в таблице вовсе без политики чтения и возвращать в панель управления только признак «секрет задан или нет». Администратор может заполнить поле, но не может прочитать то, что записал раньше. Это отличается от простого скрытия поля в интерфейсе: ограничение находится на уровне базы данных, и ни один запрос из браузера его не обойдёт. Другие места, где действует тот же принцип, мы описали в статье о защите данных.

С чего начать?

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

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