LDAP и SSO: как настроить единую аутентификацию в корпоративной инфраструктуре

LDAP и SSO: как настроить единую аутентификацию в корпоративной инфраструктуре мар, 18 2026

Представьте, что каждый день вы вводите пароль 15 раз - в почту, в CRM, в бухгалтерскую систему, в SharePoint, в внутренний портал, в чат, в отчётную систему, в HR-сервис, в VPN, в облачный диск, в приложение для тайм-трекинга, в систему учёта оборудования, в тестовый стенд, в бэкап-сервер и в админ-панель. Это не выдумка. Это реальность для многих сотрудников, у которых нет единого входа. А теперь представьте, что вы вводите пароль один раз - и всё. Ни повторов, ни напоминаний, ни сбросов. Это не магия. Это SSO. И вместе с LDAP он становится краеугольным камнем современной ИТ-инфраструктуры.

Что такое LDAP и зачем он нужен

LDAP - это не программа, не сервис, не приложение. Это протокол. Простой, старый, но невероятно надёжный. Его полное название - Lightweight Directory Access Protocol. По-русски - протокол облегчённого доступа к каталогам. Он работает как телефонная книга, только для компьютеров. Вместо имён и номеров телефонов в нём хранятся имена пользователей, их группы, почтовые адреса, права доступа, номера телефонов, отделы - всё, что нужно системе, чтобы знать: кто есть кто.

LDAP - это центральный источник правды. Если вы используете Active Directory (и почти все корпоративные сети в России используют именно его), то AD - это реализация LDAP-каталога. Всё, что вы создаёте в AD: пользователей, группы, политики - это данные, которые LDAP-сервер отдаёт другим системам. Без LDAP вы бы каждый раз создавали учётку в CRM, в почте, в ERP, в бухгалтерии - и управляли ими по отдельности. Это значит: 100 пользователей = 100 паролей, 100 учетных записей, 100 мест, где нужно вручную отключать доступ. А с LDAP - одна запись. Одна синхронизация. Один источник.

LDAP не шифрует данные. Он не аутентифицирует. Он просто хранит и отдаёт. Но именно эта простота делает его идеальным фундаментом для чего-то большего - например, для единого входа.

Что такое SSO и как он работает

SSO - Single Sign-On - это когда вы входитесь один раз, а система знает, кто вы, во всех остальных местах. Это как ключ от всех дверей в доме, который открывает и входную дверь, и дверь в гараж, и дверь в подвал - без необходимости искать разные ключи.

Как это работает? Представьте, что вы заходите на сайт корпоративного портала. Вместо того чтобы вводить логин и пароль прямо там, вы перенаправляетесь на центральный сервер - Identity Provider (IdP). Это может быть Azure AD, Keycloak, ADFS или даже ваш собственный LDAP-сервер с поддержкой SSO-протоколов. Там вы вводите учётные данные. Сервер проверяет их через LDAP-каталог, убеждается, что вы есть в системе, и выдаёт вам цифровой билет - токен. Этот токен - зашифрованный, с подписью, с датой истечения. Он не содержит вашего пароля. Он просто говорит: «Этот пользователь - Иван Петров, группа «Финансы», доступ разрешён».

Теперь вы возвращаетесь на портал. Система видит токен, проверяет подпись, убеждается, что он не поддельный, и даёт вам доступ. Потом вы переходите на CRM - та же логика. На почту - снова токен. Ни одного повторного ввода пароля. Ни одной попытки «забыл пароль». Всё происходит автоматически.

Как LDAP и SSO работают вместе

LDAP - это память. SSO - это ключ. Без памяти ключ не знает, кому принадлежать. Без ключа память не может открыть двери.

Вот как это выглядит на практике:

  1. Пользователь заходит на внутренний сайт (Service Provider).
  2. Сайт понимает: «Я не знаю, кто ты. Перенаправляю на IdP».
  3. IdP (например, Azure AD) запрашивает у LDAP-сервера: «Есть ли пользователь с логином [email protected]?»
  4. LDAP отвечает: «Да. Его имя - Иван Петров, группа - «Отдел продаж», почта - [email protected]».
  5. IdP проверяет пароль (через защищённый канал), генерирует SAML-токен или JWT, подписывает его криптографически.
  6. Токен отправляется обратно на сайт.
  7. Сайт проверяет подпись, срок действия, права - и открывает доступ.

Всё это происходит за доли секунды. Пользователь даже не замечает, что его «перебросило» на другой сервер. Он просто видит: «Вошёл - и всё работает».

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

Почему это важно для бизнеса

Экономия времени - это только начало. Главное - безопасность и контроль.

Когда у каждого сотрудника 15 паролей, кто-то обязательно использует «123456», кто-то пишет пароль на листочке, кто-то дублирует его в почте. Это - основной вектор атак. Взлом одного пароля = доступ к трём системам. С SSO - один пароль. Но он защищён MFA. И его можно отозвать мгновенно. Если сотрудник уволился - вы отключаете его в AD. И всё. Он больше не попадёт ни в одну систему. Без SSO вы бы должны были вручную зайти в 15 систем, найти его аккаунт, удалить - и скорее всего, забыли бы где-то.

Администраторы получают полный контроль. Можно настроить правила: «Только из отдела продаж могут входить в CRM», «Пользователи из HR не могут заходить в бухгалтерию с домашнего ПК», «При подозрительной активности - требовать MFA». Всё это - через централизованные политики. И всё - в одном месте.

Ещё один плюс - аудит. Вы видите, кто когда заходил, с какого устройства, где был, сколько времени провёл. Это не просто «для отчётности». Это - основа для расследования инцидентов. Если кто-то украл данные из ERP - вы смотрите логи SSO и сразу знаете: кто, когда, откуда.

Какие протоколы используются

SSO не один. Есть несколько стандартов. И каждый - для своих задач.

  • SAML - самый популярный в корпоративной среде. Особенно если вы используете Azure AD, Okta, ADFS или SaaS-сервисы типа Salesforce, Jira, Confluence. SAML работает через XML-токены. Он надёжный, поддерживает MFA, аудит, отзыв прав. Идеален для больших организаций.
  • OAuth 2.0 + JWT - чаще используется в мобильных и веб-приложениях. JWT - это компактный токен в формате JSON. Он быстрее, легче, но требует более тщательной защиты ключей. Хорош для современных сервисов, где важна скорость.
  • Kerberos - это «старый добрый» протокол, который используется внутри корпоративных доменов Windows. Он не работает через браузер, но идеален для внутренних приложений, запущенных на Windows-серверах. Например, если у вас есть локальное приложение, которое работает только в интранете - Kerberos может обеспечить SSO без ввода логина вообще. Пользователь просто включает компьютер - и сразу попадает в систему.
  • CAS - используется в университетах и образовательных учреждениях. Простой, но не так часто встречается в бизнесе.

В большинстве российских компаний - SAML или JWT поверх LDAP/AD. Это стандарт. Никто не использует CAS для CRM. Никто не настраивает Kerberos для облачного сервиса. Выбирают то, что работает с тем, что уже есть.

Практические примеры

Компания «Ростов-Транс» - средний бизнес, 300 сотрудников. У них есть:

  • Active Directory (LDAP-каталог)
  • CRM (Salesforce)
  • Почта (Microsoft 365)
  • ERP (1С:УТ 11)
  • Внутренний портал (WordPress)
  • Чат (Slack)

До SSO: сотрудники вводили пароль в AD - заходили в почту - вводили пароль снова - заходили в CRM - вводили пароль ещё раз - заходили в ERP - опять пароль. Среднее число входов в день - 8. Каждый месяц - 300 обращений в ИТ-поддержку по поводу «забыл пароль».

После SSO:

  • Настроили Azure AD как IdP.
  • Привязали его к Active Directory через LDAP-синхронизацию.
  • Настроили SAML-интеграцию с Salesforce, Slack, WordPress и 1С.
  • Включили MFA для всех.

Результат:

  • Среднее число входов в день - 1.
  • Обращений в поддержку по паролям - снизились на 92%.
  • Инциденты с утечкой паролей - исчезли.
  • Сотрудники начали чаще использовать MFA, потому что оно стало «невидимым» - не мешает, а защищает.

Это не теория. Это реальный кейс из Ростова-на-Дону. И таких компаний - десятки.

Сравнение хаоса множества паролей и простоты единого входа с символами LDAP и SSO.

Что может пойти не так

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

  • Один IdP - одна точка отказа. Если Azure AD упал - никто не может войти. Решение: настройте резервный IdP (например, Keycloak) или используйте локальный AD FS с репликацией.
  • LDAP не шифрует. Если вы используете LDAP без LDAPS (SSL/TLS), пароли могут перехватить. Всегда включайте шифрование.
  • Неправильные атрибуты. Если в LDAP не передаётся группа пользователя - SSO не знает, кто может что делать. Проверяйте, какие атрибуты передаются (memberOf, mail, department).
  • Нет MFA. SSO с паролем - это как замок без ключа. Всегда включайте двухфакторную аутентификацию. Даже если сотрудник не любит - он привыкнет.
  • Нет мониторинга. Если вы не видите логи входов - вы не контролируете доступ. Включите логирование в IdP. Следите за подозрительными попытками.

Что делать, если вы только начинаете

Не нужно сразу переносить всё в Azure AD. Начните с малого.

  1. Убедитесь, что у вас есть Active Directory (или LDAP-сервер). Если нет - начните с него. Без централизованного каталога SSO невозможен.
  2. Выберите один сервис, который чаще всего вызывает жалобы: почта, CRM, портал. Настройте для него SSO через SAML.
  3. Подключите MFA. Только для этого сервиса. Потом - для всех.
  4. Попросите 5-10 человек протестировать. Соберите обратную связь.
  5. Потом добавьте второй сервис. Потом третий.
  6. Когда будете готовы - перенесите всё.

Не пытайтесь сделать всё за неделю. Это процесс. Как строить дом: сначала фундамент, потом стены, потом крыша. LDAP - фундамент. SSO - стены. MFA - крыша. Без фундамента - ничего не держится.

Что дальше

SSO - это только начало. Следующий шаг - IAM (Identity and Access Management). Это когда вы не просто входитесь один раз, а автоматически получаете права: кто вы, в каком отделе, в какой стране, на каком устройстве - и на основе этого система сама решает: что вам можно, а что нельзя. Например: «Менеджер из Москвы - может редактировать отчёты. Менеджер из Казани - только читать».

Также стоит подумать о Zero Trust - модели, где «доверяй, но проверяй». Даже если вы внутри сети - каждый запрос проверяется. SSO с MFA и политиками - основа Zero Trust. Без SSO - Zero Trust невозможен.

Сегодня - SSO. Завтра - автоматизация доступа. Через год - искусственный интеллект, который предсказывает, кто может стать угрозой, и блокирует доступ до того, как он попытается войти. Но всё это начинается с LDAP и одного ввода пароля.

Теги: