Подписка на печатную версию:

Подписка на электронную версию:

Подшивки старых номеров журнала (печатные версии)

LXF105:Стань гуру LDAP

Материал из Linuxformat.

(Различия между версиями)

Перейти к: навигация, поиск

Текущая версия

Hardcore Linux Проверь себя на проекте для продвинутых пользователей

Содержание

1 LDAP: /home виден из далека

LDAP: /home виден из далека

Д-р Крис Браун предоставит доступ к вашей домашней директории из любого места/офиса на Земле с помощью LDAP-аутентификации из прошлой статьи.

Пусть это выдает мой возраст, но я привык к работе в настоящем офисе с настоящей дверью и реальной грудой моих вещей на полу. Дверь, возможно, была важнее всего, так как я мог почесаться или позволить себе отрыжку, не оскорбляя ничьих чувств; но и груды вещей были тоже важны – они питали мое сознание личной уникальности, а также иллюзию, что я и вправду работаю.

Рис. 1. Вот эту схему мы и попытаемся реализовать.

Ныне в порядке вещей стал «hotdesking» – один из гнусных терминов, придуманных для описания практики предоставления рабочего пространства, не привязанного к конкретному работнику. С технической точки зрения, ноутбуки, беспроводные сети и мобильные телефоны сделали «hotdesking» чрезвычайно легким. Тем не менее иногда бывает по-прежнему нужно обеспечить работу с компьютером, не привязывая к нему пользователей, и на нашем уроке мы увидим, как легко создать такое окружение в Linux.

Идея заключается в хранении всех специфических данных пользователя на центральном сервере, а не на индивидуальной рабочей станции. Короче, вот что мы хотим сделать:

Установить файловый сервер NFS для домашних директорий наших пользователей.
Настроить наши рабочие станции для автомонтирования домашних каталогов по требованию.
Установить сервер LDAP и добавить туда учетные записи наших пользователей (большую часть этого мы сделали в прошлом месяце).
Настроить рабочие станции на использование сервера LDAP для информации об учетных записях пользователей и аутентификации.

Этот урок будет шире, чем обычно. Мы переберем несколько различных технологий – NFS, LDAP, Automounter, даже немного коснемся скриптов оболочки. Рис. 1 на соседней странице изображает все в детялях.

Настройка сервера NFS

Я использую на сервере CentOS 5 (клон RHEL 5), но сгодится любой современный дистрибутив. Первым делом надо проверить, что NFS уже установлен, с помощью команд

 # rpm -qa | grep nfs
 nfs-utils-lib-1.0.8-7.2
 nfs-utils-1.0.9-16.el5

Сервер NFS очень легко настроить. Его файл конфигурации – /etc/exports., здесь задается, какие части файловой системы сервера должны быть доступны и каким клиентам. Для наших сегодняшних целей я хочу экспортировать директорию /home (место «обитания» домашних директорий пользователей) на все машины локальной сети, которая имеет IP-адрес 192.168.0.0. Для этого мне надо поместить в /etc/exports следующую строчку:

 /home 192.168.0.0/24(rw)

Опция (rw) очень важна. Без нее файловая система экспортируется в режиме «только для чтения».

Далее я запустил сервер NFS. Так как моя система – близнец Red-Hat, можно использовать для этого маленький скрипт RHEL – service:

 # service nfs start

Наконец, чтобы обеспечить старт NFS при запуске системы, я запустил команду

 # chkconfig nfs on

Вот и все, что надо было сделать!

Настройка клиента NFS

На этом этапе хорошо бы протестировать сервер NFS, попытавшись смонтировать его файловую систему /home на свои клиенты. На них я буду использовать OpenSUSE 10.3, но снова отмечу, что различия у всех дистрибутивов невелики. На случайно выбранном клиенте я попытался выполнить монтирование «вручную» так:

 # mount 192.168.0.41:/home /home

Здесь стоит отметить несколько моментов. Во-первых, 192.168.0.41 – это IP-адрес моего сервера NFS. Вы можете использовать здесь имя машины (если, конечно, оно разрешимо), но я предпочитаю вводить IP-адрес. Во-вторых, я монтирую в /home, так что моя директория будет доступна как /home и на сервере, и на клиенте. Вы не обязаны поступать так же; базовая схема предполагает помещать директории пользователей в /exports на сервере и монтировать их в /home на рабочих станциях.

При успехе монтирования вы должны иметь возможность доступа к /home на клиенте, как если бы вы сидели за сервером (на данном этапе, конечно, /home на сервере пока пуста).

Чтобы сделать это монтирование постоянным (то есть обеспечить повторное монтирование при загрузке), нужна строка в /etc/fstab типа этой:

192.168.0.41:/home /home nfs hard,intr 0 0

Будьте осторожны при редактировании этого файла – если вы повредите существующие строки, ваша система может перестать пра- вильно загружаться!

Такая организация постоянного монтирования /home с сервера в /home на всех клиентах – одна из простейших возможных схем. Ей не хватает гибкости: например, предполагается, что все пользовательские директории находятся на одном и том же сервере, и все домашние директории пользователей доступны для всех клиентов, независимо от того, кто на самом деле вошел в систему. Позднее на этом уроке мы установим Automounter, предлагающий более гибкое решение.

Рис. 2. Группы и пользователей в LDAP можно редактировать с помощью Lat.

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

Теперь переключим внимание на сервер LDAP. Я решил использовать один и тот же компьютер для LDAP и NFS, но в загруженной сети, вы, возможно, захотите использовать две отдельные машины.

На прошлом уроке мы рассмотрели создание сервера LDAP, и я показал, как добавить учетную запись пользователя вручную, редактируя LDIF-файл, и как добавить ее в каталог с помощью ldapadd. Мы рассмотрели также Lat (графический инструмент управления LDAP), как способ просмотра каталога LDAP. Вы можете использовать Lat еще и для добавления и изменения пользователей и групп в LDAP, как показано на рис. 2. Но создание учетной записи пользователя – это не просто добавление записи в LDAP: нам нужно создать домашнюю директорию и установить ей владельца и права, включить пользователя в основную группу и присвоить ему уникальный UID. Это оказалось сложнее, чем я думал: мне даже пришлось писать небольшой shell-скрипт. Но мы не боимся трудностей – мы здесь все взрослые, верно?

Мой скрипт (addldapuser) делает следующее:

Запускает программу useradd для добавления аккаунта в /etc/passwd, создания домашней директории и т.п.
Конвертирует новую созданную запись /etc/passwd в файл LDIF.
Запускает команду ldapadd для добавления записи в файл LDIF, который мы только что создали в директории LDAP.
Устанавливает пароль для пользователя.

Вот этот скрипт. Нумерация строк нужна только для ссылок на них – в файле их быть не должно:

1 useradd -m $1
  2 grep $1 /etc/passwd > newuser.in
  3 grep $1 /etc/group > newgroup.in
  4 /usr/share/openldap/migration/migrate_passwd.pl newuser.in >  newuser.ldif
  5 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/ openldap/ldap_passwd -W -f newuser.ldif
  6 /usr/share/openldap/migration/migrate_group.pl newgroup.in >  newgroup.ldif
  7 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/openldap/ldap_passwd -W -f newgroup.ldif
  8 ldappasswd -x -S -D “cn=admin,dc=example,dc=com” -y /etc/openldap/ldap_passwd “uid=$1,ou=users,dc=example,dc=com”

Строка 1 в скрипте добавляет учетную запись пользователя на сервер. Создается домашняя директория, и начальный набор файлов копируется в нее из /etc/skel. $1 – ссылка на первый аргумент, переда ваемый скрипту. Так, если вы запустите скрипт как здесь:

# ./addldapuser peter

то все вхождения $1 в скрипте будут заменены на ‘peter’. А так как наша система построена по типу Red Hat, команда useradd тоже создаст «персональную частную группу» для пользователя; имя группы будет совпадать с именем пользователя. В нашем примере создастся группа с именем peter.

Строки 2 и 3 в скрипте извлекают строки из /etc/passwd и /etc/group, ссылающиеся на только что созданные useradd учетную запись и группу, и помещают результат в newuser.in и newgroup.in. Строка 4 конвертирует учетную запись пользователя в формат LDIF (сценарий migrate_passwd.pl, используемый здесь, относится к семейству скриптов миграции от PADL Software – см. подробности в LDAP Migration Scripts).

Строка 5 добавляет пользователя в каталог LDAP. Эта операция требует аутентификации на сервере LDAP как администратора (используя DN cn=admin,dc=example,dc=com). Чтобы каждый раз не вводить пароль администратора LDAP, я поместил его в файл /etc/openldap/ldap_passwd и ссылаюсь на него с помощью опции -y в командной строке ldapadd. Чтобы заставить все работать, мне пришлось помучатся, потому что ldapadd использует полное содержание файла ldap_passwd как пароль, и вы должны убедиться, что за паролем не следует символ перевода строки, а его норовит услужливо вставить даже сверхнадежный «старик» Vi. В конце концов я создал такой файл:

# echo -n adminpw > /etc/openldap/ldap_passwd
# chmod 400 /etc/openldap/ldap_passwd

Вернемся к скрипту addldapuser. Строки 6 и 7 подобны строкам 4 и 5: они создают новую группу в LDAP. Наконец, строка 8 задает пароль для нового пользователя. Эта команда выводит строку запроса нового пароля; мне это кажется предпочтительнее, чем вводить его в открытую в командной строке.

Я могу запустить этот скрипт как здесь:

# ./addldapuser peter

и получить вывод типа такого:

adding new entry “uid=peter,ou=users,dc=example,dc=com”
adding new entry “cn=peter,ou=groups,dc=example,dc=com”

Вы должны дважды ввести ваш пароль, и оба раза сделать это правильно; в конечном итоге вы получите домашнюю директорию /home/peter, а также пользователя с именем peter (и группу с похожим именем) в каталоге LDAP. Иерархия LDAP проиллюстрирована на рис. 3. Вы также в конце получите записи для peter в локальных файлах (passwd, group и shadow), но они не будут по настоящему использоваться на рабочей станции, на которую будет заходить Peter.

Рис. 3. Структура каталога LDAP, используемая в учебнике.

Клиентская часть LDAP (SUSE)

Теперь займемся клиентской частью LDAP. Здесь есть две вещи, подлежащие настройке: файл переключателя службы имен (он говорит системе, как найти информацию об учетной записи пользователя), а также конфигурация PAM (она сообщает системе, как выполнять аутентификацию). Сперва настроим службу имен.

Немного теории: когда программы хотят найти системную информацию, они обращаются к соответствующим библиотекам, известным как «резольверы» [resolvers]. Например, чтобы найти учетную запись пользователя, программа может вызвать функцию getpwnam(), называемую так потому, что она (по традиции) ищет имя в файле паролей. Резольверы типа getpwnam() сначала сверяются с файлом /etc/nsswitch.conf; оттуда они узнают, какие программные средства надо задействовать для проведения фактического поиска. Если мы хотим иметь возможность искать информацию в LDAP, нам нужны такие строки в nsswitch.conf:

passwd: files ldap
group: files ldap

Эти строки велят резольверу сперва посмотреть в локальных файлах (то есть в /etc/passwd и /etc/group), а затем спросить сервер LDAP. В этом случае мы получим поддержку и учетных записей, привязанных к машине (в локальных файлах), и централизованных учетных записей, применимых на всех машинах (в LDAP). Например, учетная запись суперпользователя-root всегда прописана в /etc/passwd и никогда в LDAP – кому охота заблокировать себе права root на машине из-за «падения» сервера LDAP!

Далее необходимо убедиться что мы имеем соответствующую библиотеку-резольвер (/lib/libnss_ldap.so или /usr/lib/libnss_ldap, в зависимости от дистрибутива). В OpenSUSE 10.3 я просто установил пакет nss_ldap.

Вот кусочек конфигурации, необходимый в файле /etc/ldap.conf. Главные строки здесь –

host 192.168.0.41
base dc=example,dc=com

Параметр base определяет соответствующий базовый DN, который мы настроили для нашего сервера LDAP на уроке прошлого месяца. Понятно, вам придется подставить host и base из своей собственной конфигурации.

Теперь проверим функционирование, командами

# getent passwd
# getent group

Это обертки вокруг библиотек функций, а именно getpwent() и getgrent(). На выходе этих команд вы должны сначала увидеть заданные локально пароли и группы, а затем заданные в LDAP, типа учетной записи Peter, которую мы добавляли.

А вы знакомы с PAM?

Теперь пора обратить внимание на конфигурацию PAM. При чем здесь это? Так ведь PAM (Pluggable Authentication Modules, Подключаемые аутентификационные модули) является основой всей деятельности аутентификации, и мы должны настроить его на использование LDAP в качестве источника данных. (Если вы хотите узнать о PAM больше, откопайте свой экземпляр LXF99 и перейдите к моему учебнику) Теперь, в принципе, мы должны были бы внести изменения в файлы конфигурации PAM для каждого PAM-совместимого приложения, но на практике все гораздо проще: в большинстве дистрибутивов PAM настроен так, что все конфигурации PAM-совместимых программ включают в себя четыре «общих» файла в /etc/pam.d: common-account, common-auth, common-password и common-session. (Ubuntu также использует эти четыре имени, а в Red Hat используется единый файл, с именем system-auth.)

Здесь нам потребуется файл common-auth. В моем клиенте с OpenSUSE он выглядит так:

auth required pam_env.so
           auth sufficient pam_unix2.so
           auth required pam_ldap.so use_first_pass

Первая строка вызывает модуль PAM, отвечающий за определение переменных окружения. Вторая строка велит попытаться провести аутентификацию с использованием стандартных механизмов – в нашем случае это означает аутентификацию с помощью passwd и файлов shadow. Ключевое слово sufficient говорит, что если это удастся, все последующие модули не вызываются. В третьей строке запрашивается аутентификация в каталоге LDAP. Ключевое слово use_first_pass, как вы уже могли догадаться, велит PAM повторно использовать пароль, введенный в предыдущем модуле. (Без этого при входе в учетную запись LDAP вы получите приглашение ввести пароль два раза).

Кроме изменения этого файла, мы должны убедиться, что у нас установлен модуль LDAP PAM /lib/security/pam_ldap.so. На моей системе с OpenSUSE 10.3 я установил пакет pam_ldap.

Многие дистрибутивы Linux предоставляют скрипты и/или графические инструменты редактирования файлов конфигурации. Например, в OpenSUSE для этого существует модуль Yast (в основном окне Yast выберите Network Services > LDAP Client). В Red Hat присутствует графический инструмент с именем system-config-authentication. В Ubuntu есть программа auth-client-config (по крайней мере, была в релизе Gutsy Gibbon). А лично я предпочитаю знать, что творится в соответствующих файлах конфигурации.

Когда наши изменения будут внесены, Peter сможет зайти в систему на любой рабочей станции, используя данные своей учетной записи, содержащиеся в LDAP, и получить доступ к своей домашней директории, сохраненной на NFS-сервере. Peter будет воображать, что его учетная запись и файлы находятся на машине, за которой он сидит.

Порезвитесь с Automounter

Наша теперешняя схема монтирования /home с сервера в /home на клиенте имеет пару недостатков. Во-первых, все домашние директории пользователей должны жить на одном сервере. Во-вторых, внутренняя иерархия /home видна всем клиентам, независимо от того, кто зашел в систему. Использование Automounter предоставляет более гибкое решение.

Основная идея Automounter заключается в том, что файловые системы автоматически монтируются по требованию – то есть только если к ним обратились – и в том, что у них есть таймер, и они будут отсоединены, если к файловой системе не обращались в течение определенного времени (по умолчанию, десять минут). Этот процесс настраивается мастером Automounter в /etc/auto.master. В нашем случае этот файл должен содержать всего одну строку, например:

/home /etc/auto.home

Здесь говорится: «если кто-то пытается получить доступ к файл в папке, лежащей в /home, посмотрите в файле /etc/auto.home, чтобы узнать, откуда ее монтировать».

Файл auto.home должен выглядеть так:

peter 192.168.0.41:/home/peter
paul 192.168.0.42:/home/paul

В первой строке говорится о том, что директория peter (в директории /home) должна быть смонтирована с NFS-сервера 192.18.0.41. Вы можете заметить, что в этом файле я намеренно выбрал разные серверы для домашних каталогов для Peter и Paul, только чтобы доказать, что вы можете так сделать. В нашей односерверной установке, конечно же, все домашние каталоги будут браться с одного сервера, и в подобных случаях auto.home файл можно упростить до одной строки:

* 192.168.0.41:/home/&

Звездочка * в первом поле означает любое имя, а & во втором поле заменяется всем, что подставляется вместо *. Например, при запросе доступа к /home/mary (на рабочей станции) NFS в результате смонтирует 192.168.0.41:/home/mary. Другой подход заключается в централизованном хранении карт Automounter в... угадайте, где? – в каталоге LDAP. Но мы так делать не будем!

Чтобы Automounter заработал, нужно сделать следующее:

 # /etc/init.d/autofs start

и убедиться, что он стартует при загрузке:

 # chkconfig autofs on

Если вы решили использовать Automounter, убедитесь, что у вас в /home нет статически смонтированных директорий. При монтировании домашней директории с сервера вы должны отмонтировать ее:

 # umount /home

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

Идем дальше

Есть несколько проблем, для решения которых на данном уроке не нашлось места, но они, вероятно, возникнут при использовании «hotdesking» в производственных условиях: в частности, мы должны зашифровать общение с LDAP-сервером с использованием TLS и SASL и реплицировать LDAP-каталог (с использованием slurpd), чтобы обеспечить избыточность. Немало дискуссий по поводу этих вещей размещено на сайте http://www.ibm.com/developerworks/library/l-openldap/index.html. LXF

Скрипты миграции LDAP

Скрипты migrate_passwd.pl и migrate_group.pl – два из набора Perl-скриптов, предоставляемых PADL Software. В Red Hat эти скрипты установлены в директории /usr/share/openldap/migration. Скрипты не взаимодействуют с сервером LDAP напрямую: они конвертируют записи из традиционных файлов, типа /etc/passwd и /etc/group, в формат LDIF, готовый для добавления в каталог с помощью ldapadd.

В дополнение к переносу сведений из учетных записей, существуют скрипты, конвертирующие файлы /etc/hosts, /etc/services и /etc/aliases. См. более подробную информацию на http://www.padl.com/OSS/MigrationTools.html.

Мне пришлось слегка изменить файл migrate_common.ph, чтобы LDIF-файл, генерируемый скриптом миграции, походил на структуру каталога LDAP, которую я задал в прошлом месяце. (Это означает, что учетная запись пользователя размещается в узле ou=users,dc=example,dc=com , а группа – в узле ou=groups,dc=example,dc=com, как показано на Рис. 3). Я подкорректировал следующие три строки:

$DEFAULT_BASE = “dc=example,dc=com”
$NAMINGCONTEXT{‘passwd’} = “ou=users”;
$NAMINGCONTEXT{‘group’} = “ou=groups”;

Клиентская конфигурация в Ubuntu

Я также попытался использовать Ubuntu в качестве клиента. Концептуально, название службы и изменения конфигурации PAM схожи. Как всегда, дьявол кроется в деталях.

Пакеты,требуемые в Ubuntu, называются libnss-ldap и libpam-ldap. Их можно установить так:

 # sudo apt-get install libnss-ldap libpam-ldap

Сюда включен установочный скрипт, который, задав несколько вопросов, построит файлы конфигурации для резольвера libnss-ldap и модуля PAM LDAP. В сокращении, вопросы (и данные мной ответы) были такие:

 LDAP Search URI? : ldap://192.168.0.41
 DN of search base? : dc=example, dc=com
 Version of LDAP protocol? : 3
 LDAP account for root? : cn=admin,dc=example,dc=com
 LDAP root passwd? : adminpw

Ответы сохраняются в /etc/libnss-ldap.conf, кроме root-пароля LDAP: этот заносится в /etc/libnss-ldap.secret.

вот вопросы, заданные скриптом установки из модуля LDAP PAM (с ответами):

 Make local root database admin : Yes
 Does the LDAP database require login: No
 LDAP account for root: cn=admin,dc=example,dc=com
 LDAP root password: adminpw

Эти параметры заносятся в /etc/pam_ldap.conf, а пароль в /etc/pam_ldap.secret. (Почему в именах одних файлов используются подчеркивания, а в других – дефисы? Спросите чтонибудь полегче.)

Для более подробной информации загляните на https://help.ubuntu.com/community/LDAPClientAuthentication.

Получено с http://wiki2.linuxformat.ru/index.php/LXF105:%D0%A1%D1%82%D0%B0%D0%BD%D1%8C_%D0%B3%D1%83%D1%80%D1%83_LDAP

Категория: Учебники