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

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

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

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

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

Рис. 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, но в загруженной сети, вы, возможно, захотите использовать две отдельные машины.

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

В этой статье мы рассмотрели создание сервера 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 Устанавливает пароль для пользователя.

Вот этот скрипт.

#!/bin/bash
useradd -m $1
grep $1 /etc/passwd > newuser.in
grep $1 /etc/group > newgroup.in
/usr/share/openldap/migration/migrate_passwd.pl newuser.in > newuser.ldif
ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/ openldap/ldap_passwd -W -f newuser.ldif
/usr/share/openldap/migration/migrate_group.pl newgroup.in > newgroup.ldif
ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/ openldap/ldap_passwd -W -f newgroup.ldif
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 ).Строка 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. Здесь есть две вещи, подлежащие настройке: файл переключателя службы имен (он говорит системе, как найти информацию об учетной записи пользователя), а также конфигурация 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

Понятно, вам придется подставить host и base из своей собственной конфигурации.Теперь проверим функционирование, командами

getent passwd
getent group

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

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

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

sudo apt-get install libnss-ldap libpam-ldap

Сюда включен установочный скрипт, который, задав несколько вопросов, построит файлы конфигурации для резольвера libnssldap и модуля 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,d c=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/LDAPC lientAuthentication

Скрипты миграции 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. См. более подробную информацию на 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”;

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

Теперь пора обратить внимание на конфигурацию PAM. При чем здесь это? Так ведь PAM (Pluggable Authentication Modules, Подключаемые аутентификационные модули) является основой всей деятельности аутентификации, и мы должны настроить его на использование LDAP в качестве источника данных. Теперь, в принципе, мы должны были бы внести изменения в файлы конфигурации 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), чтобы обеспечить избыточность. Немало дискуссий по поводу этих вещей размещено на сайте www.ibm.com/developerworks/library/l-openldap/index.html