По данным Gartner, до 40% обращений в IT-поддержку в крупных компаниях связаны со сбросом паролей. Каждый такой тикет стоит от 15 до 70 долларов. Когда у сотрудника один пароль для Windows, другой для LMS и третий для HR-портала — это гарантированная боль. В этой статье — как мы решаем эту задачу, и почему просто «включить плагин LDAP» недостаточно для enterprise.

Три уровня интеграции: от базовой LDAP-аутентификации до сквозной синхронизации

За годы работы мы выделили три типовых сценария — от простого к сложному. Какой у вас, зависит не от желания, а от текущей IT-инфраструктуры.

Уровень 1. LDAP-аутентификация: один пароль для всего
Active Directory (или OpenLDAP) уже есть почти в каждой компании — сотрудники заходят в Windows под доменной учётной записью. Мы настраиваем штатный LDAP-плагин Moodle так, чтобы тот же логин и пароль работали в LMS: указываем контроллеры домена, порты, контексты поиска пользователей, протокол LDAP/LDAPS. Настраиваем маппинг полей: какие данные из AD попадают в профиль Moodle — email, имя, отдел, должность. Настраиваем синхронизацию: пользователи создаются при первом входе, блокируются при деактивации учётной записи в AD. Результат: сотрудник заходит в LMS под своим доменным логином-паролем, без отдельной регистрации.

Уровень 2. SSO через SAML 2.0 / OAuth2 / OpenID Connect: вход без пароля
LDAP решает вопрос синхронизации учётных данных, но пользователь всё ещё вводит пароль на странице Moodle. Второй уровень — бесшовный вход: сотрудник один раз авторизуется в корпоративной среде и дальше переходит между системами без повторного ввода. В наших проектах мы используем SAML 2.0 как основной enterprise-протокол (Moodle = Service Provider, ADFS / Keycloak / Azure AD = Identity Provider), а также OpenID Connect / OAuth2 — если компания уже использует современный IdP. В проекте для финансовой организации с 40 000 пользователей мы настроили связку ADFS → SAML → Moodle: при входе в LMS пользователь бесшовно авторизуется через корпоративный портал, без единого дополнительного клика.

Уровень 3. Глубокая интеграция: оргструктура, группы, роли
Когда нужно больше, чем просто вход — мы связываем AD и Moodle на уровне данных. Группы безопасности AD становятся учебными группами с автоматическим назначением курсов. Роли в AD транслируются в роли Moodle: «руководитель отдела» → «менеджер курса». Атрибуты — табельный номер, должность, руководитель — передаются в профиль для отчётности. Кадровые изменения — увольнение, перевод — отражаются в LMS в течение часа. Для промышленной компании с 12 заводами мы реализовали именно такой сценарий: 6 000 пользователей, каждый завод со своим OU в AD, синхронизация каждые 30 минут, нулевой ручной ввод.

Что конкретно мы настраиваем

Не «внедряем SSO» — за этими словами стоит конкретный объём работ. Вот что мы делаем в каждом проекте.

Аудит текущей инфраструктуры
Изучаем архитектуру AD/LDAP: количество контроллеров домена, версию схемы, OU-структуру, используемые IdP (ADFS, Keycloak, Azure AD). Параллельно смотрим, какие интеграции уже есть в компании — чтобы спроектировать связку без конфликтов.

Настройка LDAP-плагина Moodle
Параметры подключения: хост, порт (389/636 для LDAPS), DN для биндинга, тип сервера (MS AD, OpenLDAP, 389 DS), шифрование TLS. Маппинг полей: sAMAccountName → username, mail → email, department → кастомное поле, memberOf → когорты.

Настройка SAML / OIDC
Обмениваемся метаданными с вашим IdP, настраиваем endpoint’ы, сертификаты, алгоритмы подписи, claims и assertions для передачи атрибутов. Тестируем на пилотной группе из 20–50 пользователей.

Документация для ИБ-отдела
Готовим документ с архитектурой интеграции: протоколы, порты, модель данных, схема аутентификации. Чтобы служба безопасности могла провести аудит, не задавая вопросов.

Поэтапный запуск и мониторинг
Запускаем на пилотную группу → собираем обратную связь → расширяем на подразделение → полный запуск. Настраиваем мониторинг ошибок аутентификации и регулярную проверку синхронизации.

Защита от типовых проблем

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

Рассинхрон AD и LMS
Сотрудник сменил фамилию — AD обновился, а в Moodle осталась старая запись. Мы настраиваем инкрементальную синхронизацию: профили обновляются при каждом входе или по крону, без полной перезагрузки базы.

Конфликт ручного и автоматического создания
Администратор создал пользователя вручную, а LDAP-синхронизация пытается создать дубликат. Решение: матчинг по уникальному идентификатору — objectGUID или employeeID — дубликатов не возникает.

Блокировка уволенных сотрудников
Типичная дыра: IT-отдел деактивировал учётку в AD, а в LMS она осталась активной. Мы настраиваем автоматическую приостановку: при деактивации в AD учётная запись в Moodle блокируется, но не удаляется — история обучения сохраняется.

Отказоустойчивость
Если контроллер домена недоступен — пользователи не должны терять доступ к LMS. Настраиваем failover на резервный DC и graceful fallback: при временных сбоях AD аутентификация не обрывается.

Фильтрация групп
Если в AD 500 групп, а для обучения нужны 20 — мы не синхронизируем всё подряд. Настраиваем фильтры: какие OU и группы безопасности преобразовывать в учебные, а какие игнорировать.

Что получает бизнес

Нулевой Helpdesk по паролям LMS
Сотрудники используют доменные учётные данные. Забыл пароль — сбрасывает по стандартной Windows-процедуре, а не звонит администратору LMS.

Вход за один клик
С SSO — открыл браузер, кликнул на ссылку LMS, и ты внутри. 10–30 секунд экономии при каждом входе × сотни входов в день × 250 рабочих дней = тысячи часов в год.

Onboarding за минуты
Новый сотрудник появляется в AD — и автоматически попадает в Moodle с назначенными курсами по должности. Welcome-письмо уходит без участия человека.

Compliance и безопасность
При увольнении доступ к LMS прекращается мгновенно. Аудит входа — централизованный. Для ИБ-отдела — готовый документ с архитектурой, протоколами и моделью данных.

Выбор протокола: что и когда применяем

Протокол Когда применять Сложность
LDAP / LDAPS Базовый сценарий: синхронизация учётных данных, без SSO. Компания использует MS Active Directory или OpenLDAP, бесшовный вход не требуется 🟢 Низкая
SAML 2.0 Enterprise-стандарт для SSO. В компании уже развёрнут IdP — ADFS, Keycloak, Azure AD — и нужна единая точка входа во все сервисы 🟡 Средняя
OAuth2 / OIDC Современная альтернатива SAML. Проще в настройке, лучше поддержка мобильных устройств. IdP должен поддерживать OIDC (Azure AD, Google) 🟡 Средняя
CAS Академическая среда и legacy-системы. В корпоративном секторе применяем редко 🟠 Выше средней

Выбор протокола — не вопрос «что лучше», а вопрос «что уже работает в компании». Развёрнут ADFS — интегрируем через SAML. Используется Keycloak — работаем с ним. Azure AD — подключаем через OIDC. Мы не заставляем менять инфраструктуру под Moodle — мы настраиваем Moodle под вашу инфраструктуру.

Почему мы это знаем

Мы занимаемся разработкой интеграций для LMS с 2014 года. Настройка SSO и Active Directory — одна из самых частых задач: больше половины проектов индивидуальных LMS на Moodle, которые мы реализовали для ВТБ, Аэрофлота, АТОЛ и других крупных компаний, включали интеграцию с корпоративными службами аутентификации.

Мы настраивали SAML-аутентификацию через ADFS для 40 000 пользователей. Интегрировали Keycloak с Moodle для промышленной компании с распределённой филиальной сетью. Подключали Azure AD через OIDC для IT-компании с 3 000 разработчиков. Каждый проект — это не «включили плагин», а спроектировали архитектуру, написали middleware, провели нагрузочное тестирование и сдали документацию службе безопасности заказчика.

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