Интеграция СДО Moodle и Microsoft Active Directory. Часть 1

Ну что же, это мой первый пост в хабр-сообществе. В перспективе эта статья должна стать одной из статей в цикле рассказов о построении информационной инфраструктуры образовательного учреждения на базе Moodle ^[1], BigBlueButton ^[2], Microsoft Active Directory ^[3] и Kaspersky Security Center ^[4].
Для тех, кто не знает, Moodle — это система дистанционного обучения ^[5], этакая CMS с уклоном на образование, про неё на хабре уже немало написано ^[6]. В этой статье расскажу, как же полноценно связать её с базой пользователей, созданных в Microsoft Active Directory.

Для чего это нужно?

• Ну, во-первых, для упрощения работы администратора, ведь проще вести пользователей в одной базе, а не в двух.
• Во-вторых, для возможности делегирования функций по управлению списком пользователей другим сотрудникам. Дело в том, что в Moodle все пользователи «лежат» единым списком без разделения на структуру, и, в результате, дать кому-то права на редактирования части этого списка невозможно. А на уровне Active Directory вполне возможно делегировать права на редактирование: сотрудникам конкретного деканата на студентов этого факультета, а классным руководителям на учеников своего класса.
• В-третьих, использование такой связки позволяет организовать SSO — вход на сайт с тем же логином и паролем, с которым пользователь вошел в Windows. Мелочь, а приятно — не нужно лишний раз вводить пароль.

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

Ну что ж, будем предполагать, что уже сделано следующее:

• Настроен компьютер с серверной версией Microsoft Windows. Версия любая, можно 2003, можно 2008 (на скриншотах будет 2012). На этом сервере уже поднята роль контроллера домена. Несколько машин уже введено в домен. Пусть домен называется ad.liceum.ru, его NetBIOS имя ad_liceum_ru, а контроллер домена — pdc.ad.liceum.ru
• Настроен веб-сервер с Moodle. У меня он на базе Ubuntu 12.04. Конечно, можно установить IIS и Moodle на ту же машину, где стоит контроллер домена, но это уже другая история. Пусть сервер называется moodle.liceum.ru. На скриншотах будет Moodle 2.5, но логика принципиально не менялась с версии 1.9. Moodle уже настроен на отправку почты
• Контроллер домена, веб-сервер и машины, включенные в домен должны иметь возможность взаимодействовать друг с другом. В самом простом случаем можно просто расположить их в одной сети, но можно использовать более сложную конфигурацию с хитрой маршрутизацией и закрытием всех ненужных портов.

Управляем пользователями в Active Directory

Для начала на любой машине, включенной в домен, нужно запустить MMC-оснастку «Пользователи и компьютеры Active Directory». Конечно, можно зайти на сервер по RDP и запустить её там, как любят многие администраторы. Но если вы планируете в дальнейшем упростить свою работу, передав обязанности по ведению базы пользователей другим, рекомендую уже сейчас научиться ставить эту оснастку на клиентские машины. Делается это по-разному в разных версиях Windows. Для начала скачать: для XP ^[7], для 7 SP1 ^[8] и для 8 ^[9]. В XP оснастка появится сразу по пути Панель управления > Администрирование. В 7 и 8 после установки скачанного обновления нужно будет зайти Панель управления > Программы > Включение или отключение компонентов Windows. Там выбрать Средства удаленного администрирования сервера > Средства администрирования ролей > Средства доменых служб Active Directory и … > Средства доменых служб Active Directory > Оснастки и программы командной строки … и отметить к установке последнюю.

С помощью упомянутой оснастки создадим отдельное подразделение для пользователей. В нем мы будем хранить учетные записи всех пользователей, настраивая структуру удобным нам образом. Банально, но назову это подразделение «Пользователи».

Для того, чтобы система Moodle могла запрашивать информацию о пользователях из Active Directory, создадим специального пользователя для связи. Пусть он называется moodle_liceum_ru. Созадим его не в созданном нами контейнере «Пользователи», а в существующем изначально контейнере «Users», чтобы не было путаницы между учетными записями реальных пользователей и служебной учеткой, созданной для связи систем.

Созданую учетную запись добавим в группу «Администраторы домена».

Конечно, добавление служебной учетной записи в группу администраторов не самая хорошая идея, ведь угнав пароль администратора Moodle или получив доступ к базе данных Moodle, можно будет получить и доступ к домену, ведь в Moodle пароль пользователя для связи хранится открытым текстом. По сути, достаточно дать этой учетной записи лишь права на редактирование пользователей в подразделении «Пользователи». Как это сделать, опишу позже. Но, как говорится, есть один нюанс ^[10]. В этом случае из Moodle нельзя будет изменить пароль пользователю, если он окажется членом группы «Администратор домена». Независимо от наличия прав на редактирование на подразделение в котором находится пользователь, изменить пароль администратору домена может только другой администратор домена. Такая вот загадочная душа у Windows.

Теперь создадим в Active Directory настоящего пользователя.

Отчество, если Вы хотите, чтобы оно отображалось, лучше сразу вписать в то же поле, что и имя. Дело в том, что ни Active Directory, ни Moodle по умолчанию не предоставляют в интерфейсе поля для отчества. Сразу же стоит поменять порядок имени и фамилии в поле «Полное имя». Это позволит видеть пользователей в списке отсортированными привычным нам образом по фамилии.

После создания пользователя и настройки его пароля, вызовем свойства. Заполним поля с электронной почтой, страной и городом. Для чего это нужно? Дело в том, что дотошная система Moodle считает, что поля электронная почта, страна и город обязательны для заполнения всеми без исключения пользователями. И, если их не удастся получить из Active Directory, пользователь не сможет продолжить работу, пока не введет эти данные. Ну с городом и страной понятно, но что делать, если у пользователя нет электронной почты, или она не известна администратору? В этом случае можно придумать ему фиктивную электронную почту. При желании пользователь сможет её изменить, при этом письмо с подтверждением будет отправлено на новый адрес, а значит, то, что у пользователя нет доступа к придуманной нами почте, не будут ограничением.

Настраиваем Moodle

Зайдем в Moodle в Администрирование > Плагины > Аутентификация > Настройки аутентификации, включим плагин «Сервер LDAP»

Почему LDAP? Ну LDAP ^[11] — это такой протокол работы с иерархической базой данных. Так вот, к Active Directory можно и нужно подключиться по этому протоколу.

Ну что же, начнем настраивать плагин аутентификации. Укажем в поле «URL сервера» имя нашего сервера, добавив к нему префикс ldap://. Не забудьте, веб-сервер должен уметь правильно разрешить имя сервера LDAP в IP-адрес. Для этого можно указать контроллер домена в качестве DNS-сервера, можно и более хитро настроить DNS, можно просто вписать правильный IP в файл hosts на машине с веб-сервером. Ну можно, конечно, и в настройках Moodle указать IP вместо имени. Кстати, кто не знает, проверить, во что разрешается имя, можно при помощи команд ping и nslookup.

Конечно, если вы думаете о будущем, у Вас есть резервный контроллер домена. В этом случае его тоже стоит здесь указать. Прочие параметры в этом разделе стоит оставить по умолчанию.

Теперь нужно указать данные для подключения к серверу. Однако это не просто логин и пароль, вместо логина требуется какое-то «Отличительное имя», оно же DistinguishedName или посто DN. Что же это такое? Дело в том, что в иерархической базе данных, как и в файловой системе, может быть много объектов с одинаковыми именами. Так вот, то, что в файловой системе называется именем файла, в LDAP принято называть сommon name или CN, а то, что называется полным именем файла, то есть имя файла плюс путь к нему, называют distinguished name или DN. Ну а теперь небольшое лирическое отступление о том, как же узнать этот самый DN.

Ищем нужную информацию в LDAP

Вернемся в оснастку «Пользователи и компьютеры Active Directory». В меню Вид включим параметр Дополнительные компоненты

Теперь, когда мы будем вызывать свойства разных объектов, среди вкладок будет редактор атрибутов

В редакторе атрибутов можно посмотреть все свойства того или иного объекта. Будет там и нужное нам distinguishedName.

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

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

Продолжаем настраивать Moodle

Введем в Moodle выведанное у Active Directory отличительное имя пользователя и пароль. В моем примере отличительное имя будет CN=moodle_liceum_ru,CN=Users,DC=ad,DC=liceum,DC=ru. В поле «Тип пользователя» укажем «MS ActiveDirectory».

По умолчанию Moodle хранит у себя в базе хэши паролей. Хранит хорошо — в последних версиях применяется алгоритм bcrypt, так что поиском по базе md5 такие пароли не расшифровать. Правда, от этого мало толку, ведь если связь с Active Directory вдруг пропадет, пользователи не смогут войти в систему, несмотря на имеющуюся в ней информацию о паролях. Единственный способ воспользоваться сохраненным паролем — если администратор вручную переключит тип аутентификации для учетной записи пользователя на вариант Ручная регистрация. Но можно и это отключить, включив режим Не хранить пароли.

В поле Контейнеры укажем отличительное имя подразделения, в котором хранятся пользователи. Его можно узнать описанным выше способом. В нашем случае это будет OU=Пользователи,DC=ad,DC=liceum,DC=ru. Так как пользователи у нас хранятся и в дочерних подразделениях, включаем параметр Поиск в дочерних контейнерах.

В поле Атрибут пользователя укажем sAMAccountName. Можно, конечно, поэкспериментировать с этим параметром. Если указать здесь mail, то в качестве логина при входе в систему нужно будет указывать адрес электронной почты, если указать telephoneNumber, то номер телефона. Однако при всех альтернативных вариантах мы потом не сможем настроить автоматический вход с учетной записью из домена.

Прочие параметры оставим по умолчанию.

Вход в систему

Ну что ж, самое время попробовать зайти в Moodle c учетной записью из Active Directory.

Если всё до этого было сделано правильно, то войти в Moodle удастся. Однако, система предложит нам заполнить пустую анкету — никаких данных пользователя в Moodle не будет.

Причина проста — мы пока не сказали Moodle, откуда именно следует брать данные. За это отвечает группа параметров «Сопоставление данных». Заполним поля при помощи полученной ранее таблички.

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

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

Проверка обновления данных

А как пользоваться параметрами Обновление локальной учетной записи, Обновление внешней учетной записи и Блокировка значения при сопоставлении данных?

Такими данными, как, например, имя и фамилия хотелось бы управлять исключительно из Active Directory. Это нужно, например, для того, чтобы ученики не понаписали вместо имени и фамилии всякую ерунду. А при изменении данных в AD, хотелось бы максимально быстро их обновить в Moodle. Для таких вариантов подойдет комбинация При каждом входе, Никогда, Заблокровано.

В моем примере адреса электронной почты пользователей неизвестны, поэтому вместо них придуманы фиктивные. Такой подход позволяет пользователям начать работу в системе сразу, а затем, при желании, заменить адрес электронной почты на настоящий, чтобы, например, начать получать уведомления. Если хочется, чтобы пользователи обязательно ввели электронную почту при первом входе, это поле не следует заполнять в Active Directory. Для электронной почты, я использую вариант При каждом входе, При обновлении, Разблокировано. Это позволяет обновить данные в AD при обновлении их в Moodle, и наоборот.

Ну что, теперь проверим, обновляются ли данные. Выйдем из Moodle, исправим электронную почту пользователя в Active Directory и снова зайдем в Moodle. В профиле пользователь должна отобразиться новая почта.
Теперь изменим электронную почту из Moodle. На почту будет отправлено подтверждение. Адрес в Moodle и в Active Directory должен будет измениться сразу после подтверждения нового адреса.

Ну а о том, как настроить обноление паролей в Active Directory из Moodle, как разрешить пользователям самостоятельно создавать учетные записи, и, конечно же, как входить в Moodle не вводя пароль — обо всём этом я надеюсь рассказать в следующих частях. Если, конечно, кто-нибудь пришлет инвайт.

Автор: Vadimonus

Источник ^[12]