Ну что же, это мой первый пост в хабр-сообществе. В перспективе эта статья должна стать одной из статей в цикле рассказов о построении информационной инфраструктуры образовательного учреждения на базе Moodle, BigBlueButton, Microsoft Active Directory и Kaspersky Security Center.
Для тех, кто не знает, Moodle — это система дистанционного обучения, этакая CMS с уклоном на образование, про неё на хабре уже немало написано. В этой статье расскажу, как же полноценно связать её с базой пользователей, созданных в 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 SP1 и для 8. В XP оснастка появится сразу по пути Панель управления > Администрирование. В 7 и 8 после установки скачанного обновления нужно будет зайти Панель управления > Программы > Включение или отключение компонентов Windows. Там выбрать Средства удаленного администрирования сервера > Средства администрирования ролей > Средства доменых служб Active Directory и … > Средства доменых служб Active Directory > Оснастки и программы командной строки … и отметить к установке последнюю.
С помощью упомянутой оснастки создадим отдельное подразделение для пользователей. В нем мы будем хранить учетные записи всех пользователей, настраивая структуру удобным нам образом. Банально, но назову это подразделение «Пользователи».
Для того, чтобы система Moodle могла запрашивать информацию о пользователях из Active Directory, создадим специального пользователя для связи. Пусть он называется moodle_liceum_ru. Созадим его не в созданном нами контейнере «Пользователи», а в существующем изначально контейнере «Users», чтобы не было путаницы между учетными записями реальных пользователей и служебной учеткой, созданной для связи систем.
Созданую учетную запись добавим в группу «Администраторы домена».
Конечно, добавление служебной учетной записи в группу администраторов не самая хорошая идея, ведь угнав пароль администратора Moodle или получив доступ к базе данных Moodle, можно будет получить и доступ к домену, ведь в Moodle пароль пользователя для связи хранится открытым текстом. По сути, достаточно дать этой учетной записи лишь права на редактирование пользователей в подразделении «Пользователи». Как это сделать, опишу позже. Но, как говорится, есть один нюанс. В этом случае из Moodle нельзя будет изменить пароль пользователю, если он окажется членом группы «Администратор домена». Независимо от наличия прав на редактирование на подразделение в котором находится пользователь, изменить пароль администратору домена может только другой администратор домена. Такая вот загадочная душа у Windows.
Теперь создадим в Active Directory настоящего пользователя.
Отчество, если Вы хотите, чтобы оно отображалось, лучше сразу вписать в то же поле, что и имя. Дело в том, что ни Active Directory, ни Moodle по умолчанию не предоставляют в интерфейсе поля для отчества. Сразу же стоит поменять порядок имени и фамилии в поле «Полное имя». Это позволит видеть пользователей в списке отсортированными привычным нам образом по фамилии.
После создания пользователя и настройки его пароля, вызовем свойства. Заполним поля с электронной почтой, страной и городом. Для чего это нужно? Дело в том, что дотошная система Moodle считает, что поля электронная почта, страна и город обязательны для заполнения всеми без исключения пользователями. И, если их не удастся получить из Active Directory, пользователь не сможет продолжить работу, пока не введет эти данные. Ну с городом и страной понятно, но что делать, если у пользователя нет электронной почты, или она не известна администратору? В этом случае можно придумать ему фиктивную электронную почту. При желании пользователь сможет её изменить, при этом письмо с подтверждением будет отправлено на новый адрес, а значит, то, что у пользователя нет доступа к придуманной нами почте, не будут ограничением.
Настраиваем Moodle
Зайдем в Moodle в Администрирование > Плагины > Аутентификация > Настройки аутентификации, включим плагин «Сервер LDAP»
Почему LDAP? Ну LDAP — это такой протокол работы с иерархической базой данных. Так вот, к 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.
Кстати, самое время посмотреть, как называются поля, в которых хранятся всякие данные пользователя. Путем сопоставления того, что мы вводили в карточке пользователя и того, что мы видим в редакторе атрибутов, составим табличку.
| Значение | Атрибут |
|---|---|
| Фамилия | sn |
| Имя | givenName |
| Логин Windows | sAMAccountName |
| Электронная почта | |
| Город | l |
| Страна | с |
Наблюдательные заметят, что страна хранится дважды — полным названием в атрибуте 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
