Журнал LinuxFormat - перейти на главную

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

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Hardcore Linux Проверь себя на проекте для продвинутых пользователей

Содержание

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

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

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


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

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

  1. Установить файловый сервер NFS для домашних директорий наших пользователей.
  2. Настроить наши рабочие станции для автомонтирования домашних каталогов по требованию.
  3. Установить сервер LDAP и добавить туда учетные записи наших пользователей (большую часть этого мы сделали в прошлом месяце).
  4. Настроить рабочие станции на использование сервера 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, предлагающий более гибкое решение.


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

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

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

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

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

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

  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.


Клиентская часть 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://wiki.linuxformat.ru/wiki/index.php?title=LXF105:%D0%A1%D1%82%D0%B0%D0%BD%D1%8C_%D0%B3%D1%83%D1%80%D1%83_LDAP&oldid=7744»
Персональные инструменты
купить
подписаться
Яндекс.Метрика