Интеграция с корпоративным SSO и Active Directory: как построить единый вход без хаоса с паролями

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

Типичная ситуация в компании среднего и крупного размера: почта, корпоративный портал, CRM, HR-система, таск-трекер, 1С и десяток внутренних сервисов — и у каждого свой логин с паролем. Новый сотрудник получает доступ по частям, иногда неделями; уволенный — теряет доступ тоже по частям, и это уже не удобство, а риск информационной безопасности. Разрозненная аутентификация усложняет и аудит: сложно быстро ответить на вопрос, кто и куда имеет доступ прямо сейчас.

Материал будет полезен ИТ-директорам и руководителям ИБ, которые планируют навести порядок с доступом; системным администраторам, которым предстоит техническая реализация; и менеджерам, которым нужно понимать, из чего складывается такой проект и каких сюрпризов ждать — особенно в контексте импортозамещения и требований регуляторов.

Простое объяснение темы

SSO (Single Sign-On) — это не отдельный протокол, а принцип: пользователь один раз проходит проверку личности, а дальше перемещается между связанными системами без повторного ввода пароля. За этим стоит разделение ролей между двумя сторонами:

• Identity Provider (IdP), провайдер идентификации, — система, которая хранит учётные записи и подтверждает, что пользователь — это действительно он.
• Service Provider (SP) — любое приложение, которое доверяет IdP и принимает от него подтверждение, не проверяя пароль самостоятельно.

Active Directory (AD) — служба каталогов Microsoft, которая долгое время была стандартным хранилищем учётных записей в корпоративных сетях на Windows. AD сама по себе — не протокол SSO, а именно каталог: она хранит пользователей, группы, компьютеры и политики. Единый вход поверх AD в классической схеме реализовывался либо через Kerberos (аутентификация внутри локальной сети), либо через надстройку Active Directory Federation Services (AD FS), которая уже говорила по протоколам SAML или OpenID Connect с внешними и облачными сервисами.

Как работает процесс: протоколы и роли

SAML, OAuth 2.0 и OpenID Connect — не конкуренты, а разные задачи

Три термина путают чаще всего, хотя они решают разные проблемы:

• SAML (Security Assertion Markup Language) — зрелый XML-based стандарт, изначально созданный для корпоративной среды. Он традиционно используется в корпоративных инфраструктурах и хорошо подходит для интеграции с Active Directory и внутренними системами, где требуется строгий контроль доступа и формализованные политики безопасности [1]. Он и сейчас остаётся рабочим стандартом для внутренних веб-приложений и legacy-систем.
• OAuth 2.0 — это не протокол аутентификации, а фреймворк авторизации: он решает задачу «дать приложению доступ к ресурсу от имени пользователя», а не «подтвердить, кто пользователь». Именно поэтому чистый OAuth 2.0 не годится для входа сам по себе.
• OpenID Connect (OIDC) — надстройка над OAuth 2.0, которая добавляет как раз то, чего не хватает OAuth: подтверждённую идентичность пользователя в виде токена. OIDC используется в JSON/REST-формате, что делает его удобнее для мобильных и современных веб-приложений, тогда как SAML остаётся тяжеловеснее в реализации, но привычнее в корпоративных ИТ-ландшафтах.

Практический вывод: если в компании много legacy-приложений с уже готовой поддержкой SAML — стоит остаться на SAML; для новых сервисов, API и мобильных клиентов разумнее закладывать OpenID Connect. Многие организации сейчас держат оба протокола одновременно, потому что переписывать интеграции только ради унификации протокола обычно нерентабельно.

Kerberos и LDAP — уровень сети, а не уровень веб-приложений

Отдельная история — Kerberos, протокол для прозрачного входа внутри доверенной сети на основе билетов. Пользователь входит в ОС с доменной учётной записью, а контроллер домена выдаёт билет, который рабочая станция использует при обращении к внутренним сервисам [2].

Браузер может передать сервисный билет приложению без повторной формы входа. Для такого сценария важны корректные DNS и SPN, синхронизация времени и доверие между участниками. За пределами корпоративной сети обычно требуется VPN или другой предусмотренный архитектурой защищённый доступ.

LDAP (Lightweight Directory Access Protocol) часто путают с протоколом SSO, но это протокол доступа к каталогу — то есть способ «спросить» у AD или её аналога, существует ли такой пользователь и в каких он группах. Сам по себе LDAP не обеспечивает единый вход, а служит источником данных для систем, которые проверяют пользователя.

Как выглядит типовой цикл входа через IdP

Независимо от конкретного протокола, схема входа обычно выглядит так: сотрудник открывает сервис (Service Provider), тот перенаправляет пользователя на страницу входа IdP, если он ещё не авторизован; пользователь вводит учётные данные, IdP проверяет их и выдаёт токен доступа, который возвращается обратно в сервис [3] и подтверждает личность без повторного запроса пароля. Дальше при переходе в соседнюю систему, подключённую к тому же IdP, экран логина уже не появляется — сессия считается подтверждённой.

Российская специфика: почему тема AD и SSO выглядит сейчас иначе

До 2022 года типовая схема российской компании ничем не отличалась от мировой: Active Directory как каталог плюс AD FS или сторонний IdP поверх него для внешних сервисов. Ситуация изменилась по двум причинам одновременно — уходом вендора и ужесточением требований к защите информации.

Уход Microsoft и потеря актуальности AD FS

Microsoft предлагал сервис Active Directory Federation Services, но из-за ухода компании с российского рынка решение потеряло свою актуальность и стало рискованным в использовании [3]. На практике это означает отсутствие обновлений безопасности, невозможность получить официальную поддержку и риски при последующем аудите или проверке регулятора. Для компаний, которые не подпадают под жёсткие требования к российскому ПО, технически AD и AD FS ещё может продолжать работать — но с рисками, которые стоит явно осознавать, а не откладывать «на потом».

Российские аналоги службы каталогов

Рынок отреагировал на уход Microsoft набором отечественных продуктов. Наиболее заметные:

• ALD Pro — отечественный программный продукт, созданный на основе FreeIPA, который обеспечивает централизованное управление учётными записями, реализует единую точку аутентификации и позволяет настраивать рабочее окружение пользователей с помощью групповых политик [4]. Разработчик — «Группа Астра», продукт ориентирован в первую очередь на Linux-инфраструктуру, в том числе Astra Linux.
• «РЕД АДМ», «Атом.Домен», «Альт Домен», Avanpost DS, MultiDirectory — другие отечественные решения того же класса на рынке служб каталогов [5][6], каждое со своими нюансами совместимости с Windows-клиентами и групповыми политиками.
• Samba DC — свободное решение с более полной совместимостью именно с Windows-клиентами и классическими групповыми политиками, но менее зрелое для Linux-окружений.
• FreeIPA — open-source решение, входящее в стандартную поставку Astra Linux SE, поддерживающее Kerberos, LDAP, DNS и собственный центр сертификации [7], но без «галочного» интерфейса, привычного администраторам Windows — конфигурация идёт через CLI или веб-консоль.

Выбор между Samba DC-based решениями и FreeIPA-based обычно определяется составом инфраструктуры: если планируется продолжать управлять преимущественно Windows-компьютерами, Samba AD подходит лучше, а если новая инфраструктура строится в основном на Linux, продукты на базе FreeIPA становятся более логичным выбором [8]. Отраслевой обзор также фиксирует ключевое отличие: Samba DC совместим с AD, хотя и не полностью, тогда как FreeIPA — более зрелое решение именно потому, что его разработка ведётся дольше [9].

Миграция редко бывает «бесшовной». Один из практических обзоров описывает типовой план: развернуть минимум два сервера FreeIPA для отказоустойчивости, перенести пользователей и группы через скрипты, настроить интеграцию прикладного ПО (1С, веб-приложений) и поэтапно переводить рабочие места с Windows на российскую ОС — для 100–500 рабочих мест такой переход обычно занимает 3–6 месяцев, для 1000+ мест — до года [7]. Масштаб проекта может быть и заметно крупнее: например, один из государственных фондов оценил переход на отечественный каталог с бюджетом более миллиарда рублей и сроком реализации около одиннадцати месяцев [10].

Российские сервисы IdP / SSO поверх каталога

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

• Blitz Identity Provider — продукт компании РЕАК СОФТ, изначально разработавшей единую систему идентификации и аутентификации для портала «Госуслуги» [11]. Решение зарегистрировано в реестре российского ПО и сертифицировано на соответствие требованиям информационной безопасности ФСТЭК России [12], поддерживает SAML, OpenID Connect/OAuth 2.0, WS-Federation и RADIUS.
• Avanpost, Indeed Access Manager — другие отечественные IAM/SSO-платформы, которые чаще фигурируют в проектах импортозамещения крупных организаций.
• Keycloak — открытое решение (изначально от Red Hat), не имеющее российского происхождения, но широко используемое как в мировой, так и в российской практике благодаря отсутствию лицензионных платежей и зрелой поддержке протоколов [13].

Прямое сравнение этих трёх подходов в одном из технических обзоров подводит к выводу: Keycloak гибкий, широко распространённый и хорошо документированный, но разработан за рубежом, что может создавать сложности с локальной поддержкой, тогда как Blitz Identity Provider и другие российские решения ориентированы на локальные требования [14], хотя различия между продуктами на уровне таблиц сравнения часто невелики, и выбор в итоге определяется деталями конкретной инфраструктуры, а не общими характеристиками.

Требования регуляторов: 152-ФЗ, ФСТЭК и КИИ

Для компаний, которые обрабатывают персональные данные, работают как государственные информационные системы (ГИС) или относятся к субъектам критической информационной инфраструктуры (КИИ), выбор конкретного решения для аутентификации — не техническая деталь, а предмет регулирования.

Ключевые ориентиры:

• Нормативная база зависит от статуса информационной системы. С 1 марта 2026 года приказ ФСТЭК № 117 устанавливает требования для государственных информационных систем и иных информационных систем государственных органов, государственных унитарных предприятий и государственных учреждений; он заменил приказ № 17. Само использование SSO или Active Directory не делает приказ № 117 применимым [22].
• Для значимых объектов критической информационной инфраструктуры применяется отдельная нормативная база, включая приказ ФСТЭК № 239. Конкретные меры зависят от категории значимости и модели угроз, поэтому их нельзя автоматически переносить на любую корпоративную систему с единым входом [23].
• Для информационных систем персональных данных уровень защищённости определяют по постановлению Правительства № 1119, а конкретные меры выбирают с учётом актуальных угроз. Необходимость сертифицированного средства определяется применимыми требованиями к конкретной системе, а не самим фактом внедрения SSO [24].

Практический вывод для проекта: прежде чем выбирать конкретный продукт для SSO или каталога, стоит сначала определить класс/уровень защищённости системы и то, распространяются ли на неё требования 187-ФЗ о КИИ — это сузит список допустимых решений задолго до сравнения функциональности.

Варианты реализации и интеграции

На практике встречаются три типовых сценария, и они не исключают друг друга:

1. Только внутренняя сеть, Windows-инфраструктура. Если весь периметр — доверенная локальная сеть с Windows-клиентами, Kerberos/SPNEGO поверх AD или её российского аналога закрывает задачу прозрачного входа без дополнительного слоя IdP. Плюс — минимум инфраструктурных изменений; минус — схема не масштабируется на облачные и внешние сервисы.
2. Смешанная инфраструктура (офис + удалённые сотрудники + SaaS). Здесь между каталогом и приложениями появляется отдельный сервер аутентификации — Blitz IDP, Keycloak или аналог, — который говорит с каталогом по LDAP, а с приложениями — по SAML или OpenID Connect. Именно такая архитектура типична для среднего и крупного бизнеса сегодня.
3. Гетерогенная среда с историческими интеграциями. Часть сотрудников в каталоге, часть систем подключена напрямую, часть — через легаси-механизмы. Практический кейс внедрения такой схемы описывает ситуацию, когда в инфраструктуре компании работало 50–60 систем с разной историей внедрения и правилами интеграции, офисные сотрудники были заведены в Active Directory, и корпоративные системы уже были к нему подключены [18] — а задачей проекта было объединить всё это через единую точку входа, не переписывая каждую систему заново.

Для случаев, когда приложение не умеет говорить ни по SAML, ни по OIDC, а поддерживает только базовую HTTP-аутентификацию, технология Web SSO может быть реализована в виде обратного прокси перед приложением, который берёт на себя проверку и передаёт легаси-системе уже готовую сессию [19] — это позволяет подключить к SSO даже старое ПО без изменения его кода.

Практические этапы внедрения

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

1. Инвентаризация систем и сценариев входа. Список приложений, поддерживаемые ими протоколы, количество пользователей, требования к ролям и группам доступа.
2. Определение регуляторного контура. Проверка, относится ли система к ИСПДн, ГИС или КИИ, и какой уровень защищённости или категория значимости у неё установлена — это определяет обязательность сертифицированных средств и МФА.
3. Выбор каталога и IdP. С учётом Windows- или Linux-инфраструктуры, требований к сертификации и наличия уже работающих интеграций.
4. Пилотная интеграция одного-двух приложений. Настройка client/realm или Relying Party, маппинг атрибутов и групп, проверка сценариев логина и логаута.
5. Настройка МФА там, где это требуется регулятором или политикой компании.
6. Поэтапное подключение остальных систем, начиная с наиболее критичных или наиболее «болезненных» с точки зрения количества обращений в поддержку.
7. Тестирование сценариев отзыва доступа — увольнение сотрудника должно мгновенно закрывать доступ везде, а не только в одной системе.
8. Документирование регламентов — порядок создания, блокировки и удаления учётных записей, что отдельно требуется приказами ФСТЭК.
9. Плановый вывод легаси-схем (например, старого AD FS) после подтверждения стабильной работы новой схемы.

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

Ограничения, ошибки и риски

• Разные требования к токенам у разных приложений. Даже в рамках одного протокола каждое приложение может ожидать свой набор claims и scopes. Опыт внедрения SSO для инфраструктурных сервисов подтверждает: универсальной схемы настройки нет — протоколы, scopes и мапперы приходится настраивать индивидуально для каждого клиента, а ошибки с базовыми настройками realm и маппингов встречаются часто [20].
• Kerberos/SSO работает только внутри доверенного периметра. Сотрудники на удалёнке или в смешанных сетях потребуют отдельного сценария — например, веб-формы входа через тот же IdP.
• Миграция каталога — не разовая замена файла, а поэтапный проект. Переход с AD на российский аналог требует переноса пользователей, групп и, отдельно, повторной настройки интеграций прикладного ПО — часть их придётся тестировать заново.
• Затраты растут при точечных интеграциях без общей точки обмена. Наблюдение из корпоративной практики: при отсутствии единой точки обмена затраты на интеграцию растут, поскольку каждая система вынуждена интегрироваться с другими смежными системами по отдельности, и для каждого случая приходится писать отдельные интеграционные адаптеры [21].
• Решение без требуемого сертификата в регулируемом контуре. Риск возникает там, где применимые требования прямо предусматривают сертифицированные средства. Это проверяют после определения статуса системы и модели угроз, до выбора конкретного IdP.
• Единая точка входа — это и единая точка отказа. Если IdP недоступен, недоступны все подключённые системы одновременно — стоит заранее продумать отказоустойчивость самого сервера аутентификации.

Рекомендации по выбору решения

Готового рецепта «на все случаи» не существует, но есть ориентиры:

• Если инфраструктура преимущественно на Windows и задача — сохранить привычные групповые политики, разумно смотреть в сторону Samba DC-based решений; если инфраструктура смещается в Linux — в сторону FreeIPA-based продуктов вроде ALD Pro.
• Если для конкретной системы действительно установлено требование использовать сертифицированное средство, список подходящих продуктов сужается. Для остальных контуров выбор Keycloak, отечественного IdP или другого решения обосновывают архитектурой, угрозами и требованиями бизнеса.
• Если регуляторных ограничений нет и в приоритете гибкость, открытый исходный код и отсутствие лицензионных платежей, Keycloak и его аналоги остаются рабочим вариантом — но стоит закладывать время на кастомную настройку под конкретные бизнес-приложения.
• Не всегда нужна разработка «с нуля»: если задача — точечно подключить одно-два приложения к уже существующему IdP по стандартному протоколу, обычно достаточно настройки, а не написания собственного кода интеграции.

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

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

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

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

Вывод

SSO поверх Active Directory или её отечественного аналога — это не единая технология, а комбинация протоколов и продуктов, которые решают разные части одной задачи: каталог хранит пользователей, IdP подтверждает личность, а протоколы SAML, OIDC и Kerberos передают это подтверждение конкретным приложениям.

В российских условиях к этому добавляется два дополнительных слоя решений: практическая замена Microsoft AD и AD FS отечественными продуктами и обязательность учитывать требования ФСТЭК там, где система подпадает под регулирование персональных данных, ГИС или КИИ. Прежде чем сравнивать конкретные продукты, стоит сначала честно ответить на два вопроса: какая инфраструктура уже есть и какой регуляторный контур применим к системе — от этого зависит реальный список подходящих вариантов, а не наоборот.

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

Источники

[1] kontur.ru — Технология единого входа (SSO): как помогает пользователям — https://kontur.ru/aegis/blog/83681-tehnologiya_edinogo_vhoda_sso

[2] multifactor.ru — Настройка среды единого входа (SSO) на основе Kerberos — https://multifactor.ru/docs/self-service-portal/ssp-sso-na-osnove-kerberos/

[3] empldocs.ru — Технология единого входа SSO в КЭДО — https://empldocs.ru/tekhnologiya-edinogo-vhoda-sso-kedo

[4] anti-malware.ru — ALD Pro: обзор российской службы каталога для замены Microsoft Active Directory — https://www.anti-malware.ru/reviews/ALD-Pro-3-2

[5] multidirectory.ru — Надёжный аналог Active Directory: российская служба каталогов — https://multidirectory.ru/blog/alternativy-active-directory/

[6] cyberleninka.ru — Замена Active Directory на отечественные аналоги: анализ, выбор и внедрение — https://cyberleninka.ru/article/n/zamena-active-directory-na-otechestvennye-analogi-analiz-vybor-i-vnedrenie

[7] softdefence.ru — Замена Active Directory — FreeIPA, ALD Pro, Samba DC — https://softdefence.ru/import-zameschenie/active-directory-zamena

[8] avanpost.ru — Российские альтернативы Microsoft Active Directory, как на них мигрировать — https://www.avanpost.ru/news/alternativy-microsoft-active-directory

[9] habr.com — Обзор РЕД АДМ и Атом.Домен: новые альтернативы службе каталогов MS Active Directory — https://habr.com/ru/companies/k2tech/articles/761898/

[10] cnews.ru — Феерия импортозамещения: отказ от Microsoft Active Directory в госведомстве — https://www.cnews.ru/news/top/2026-01-20_feeriya_importozameshcheniya

[11] anti-malware.ru — Обзор Blitz Identity Provider — https://www.anti-malware.ru/reviews/Blitz_Identity_Provider

[12] identityblitz.ru — Сервер управления аутентификацией Blitz Identity Provider — https://identityblitz.ru/products/blitz-identity-provider/

[13] trueengineering.ru — Keycloak: внедрение единой системы идентификации — https://www.trueengineering.ru/blog/sso-keycloak

[14] timeweb.com — Как настроить SSO на примере Keycloak, Blitz Identity Provider и Trusted.ID — https://timeweb.com/ru/community/articles/kak-nastroit-sso-na-primere-keycloak-blitz-identity-provider-i-trusted-id

[15] fstec.ru — Требования, утверждённые приказом ФСТЭК России от 11 апреля 2025 г. № 117 — https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/trebovaniya-utverzhdeny-prikazom-fstek-rossii-ot-11-aprelya-2025-g-n-117

[16] sgrc.cyberosnova.ru — Приказ ФСТЭК №239: полный разбор требований к значимым объектам КИИ — https://sgrc.cyberosnova.ru/blog/prikaz-fstek-239-chto-trebuet/

[17] kontur.ru — Двухфакторная аутентификация и требования регуляторов: как выполнить 152-ФЗ и приказы ФСТЭК — https://kontur.ru/aegis/blog/85496-dvuhfaktornaya_autentifikaciya_i_trebovaniya_regulyatorov

[18] trueengineering.ru — Кейс: внедрение SSO на Keycloak в сети ресторанов — https://www.trueengineering.ru/cases/keycloak-sso-centralized-authentication-corporate-systems

[19] avanpost.ru — Технология единой аутентификации SSO (Single Sign-On) — https://www.avanpost.ru/publications/296/

[20] habr.com — SSO через Keycloak для инфраструктурных сервисов: часть 2, практика — https://habr.com/ru/companies/oleg-bunin/articles/936866/

[21] habr.com — Keycloak в Enterprise: сквозной проход по внешним и внутренним сервисам — https://habr.com/ru/companies/rshb/articles/724508/

[22] Официальное опубликование правовых актов — приказ ФСТЭК России № 117 — https://publication.pravo.gov.ru/document/0001202506170011

[23] Официальное опубликование правовых актов — приказ ФСТЭК России № 239 — https://publication.pravo.gov.ru/Document/View/0001201803270041

[24] Правительство России — постановление № 1119 — https://government.ru/docs/6339/