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

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

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(''LDAP'': /home виден из далека)
(''LDAP'': /home виден из далека: викификация, оформление, иллюстрация)
 
Строка 9: Строка 9:
 
работаю.
 
работаю.
  
{{Врезка|Содержание=[[Изображение:LXF105_83_1.jpg|Рис. 1]] Рис. 1. Вот эту схему мы и попытаемся реализовать. |Ширина=300px}}
+
{{Врезка|Содержание=[[Изображение:LXF105_83_1.jpg|Рис. 1|300px]]Рис. 1. Вот эту схему мы и попытаемся реализовать. |Ширина=300px}}
  
 
Ныне в порядке вещей стал «hotdesking» – один из гнусных терминов, придуманных для описания практики предоставления рабочего
 
Ныне в порядке вещей стал «hotdesking» – один из гнусных терминов, придуманных для описания практики предоставления рабочего
Строка 72: Строка 72:
 
конечно, '''/home''' на сервере пока пуста).
 
конечно, '''/home''' на сервере пока пуста).
  
    Чтобы сделать это монтирование постоянным (то есть обеспечить
+
Чтобы сделать это монтирование постоянным (то есть обеспечить
повторное монтирование при загрузке), нужна строка в /etc/fstab типа
+
повторное монтирование при загрузке), нужна строка в '''/etc/fstab''' типа
 
этой:
 
этой:
 +
 
  192.168.0.41:/home /home nfs hard,intr 0 0
 
  192.168.0.41:/home /home nfs hard,intr 0 0
    Будьте осторожны при редактировании этого файла – если вы
+
 
 +
Будьте осторожны при редактировании этого файла – если вы
 
повредите существующие строки, ваша система может перестать пра-
 
повредите существующие строки, ваша система может перестать пра-
 
вильно загружаться!
 
вильно загружаться!
    Такая организация постоянного монтирования /home с сервера в
+
 
/home на всех клиентах – одна из простейших возможных схем. Ей не
+
Такая организация постоянного монтирования '''/home''' с сервера в
 +
'''/home''' на всех клиентах – одна из простейших возможных схем. Ей не
 
хватает гибкости: например, предполагается, что все пользовательские
 
хватает гибкости: например, предполагается, что все пользовательские
 
директории находятся на одном и том же сервере, и все домашние
 
директории находятся на одном и том же сервере, и все домашние
 
директории пользователей доступны для всех клиентов, независимо
 
директории пользователей доступны для всех клиентов, независимо
 
от того, кто на самом деле вошел в систему. Позднее на этом уроке мы
 
от того, кто на самом деле вошел в систему. Позднее на этом уроке мы
установим Automounter, предлагающий более гибкое решение.
+
установим ''Automounter'', предлагающий более гибкое решение.
Настраиваем сервер LDAP
+
 
Теперь переключим внимание на сервер LDAP. Я решил использовать
+
{{Врезка|Содержание=[[Изображение:LXF105_85_1.jpg|Рис. 2|300px]]Рис. 2. Группы и пользователей в ''LDAP'' можно редактировать с помощью ''Lat''.|Ширина=300px}}
один и тот же компьютер для LDAP и NFS, но в загруженной сети, вы,
+
 
 +
===Настраиваем сервер ''LDAP''===
 +
 
 +
Теперь переключим внимание на сервер ''LDAP''. Я решил использовать
 +
один и тот же компьютер для ''LDAP'' и ''NFS'', но в загруженной сети, вы,
 
возможно, захотите использовать две отдельные машины.
 
возможно, захотите использовать две отдельные машины.
    На прошлом уроке мы рассмотрели создание сервера LDAP, и я
+
 
показал, как добавить учетную запись пользователя вручную, редак-
+
На прошлом уроке мы рассмотрели создание сервера ''LDAP'', и я
тируя LDIF-файл, и как добавить ее в каталог с помощью ldapadd. Мы
+
показал, как добавить учетную запись пользователя вручную, редактируя '''LDIF'''-файл, и как добавить ее в каталог с помощью ''ldapadd''. Мы
рассмотрели также Lat (графический инструмент управления LDAP),
+
рассмотрели также ''Lat'' (графический инструмент управления ''LDAP''),
как способ просмотра каталога LDAP. Вы можете использовать Lat
+
как способ просмотра каталога ''LDAP''. Вы можете использовать ''Lat''
еще и для добавления и изменения пользователей и групп в LDAP, как
+
еще и для добавления и изменения пользователей и групп в ''LDAP'', как
показано на рис. 2 (на обороте). Но создание учетной записи пользо-
+
показано на рис. 2. Но создание учетной записи пользователя – это не просто добавление записи в ''LDAP'': нам нужно создать
вателя – это не просто добавление записи в LDAP: нам нужно создать
+
 
домашнюю директорию и установить ей владельца и права, включить
 
домашнюю директорию и установить ей владельца и права, включить
пользователя в основную группу и присвоить ему уникальный UID. Это
+
пользователя в основную группу и присвоить ему уникальный '''UID'''. Это
оказалось сложнее, чем я думал: мне даже пришлось писать неболь-
+
оказалось сложнее, чем я думал: мне даже пришлось писать небольшой ''shell''-скрипт. Но мы не боимся трудностей – мы здесь все взрослые, верно?
шой shell-скрипт. Но мы не боимся трудностей – мы здесь все взрос-
+
 
лые, верно?
+
Мой скрипт (''addldapuser'') делает следующее:
    Мой скрипт (addldapuser) делает следующее:
+
# Запускает программу ''useradd'' для добавления аккаунта в '''/etc/passwd''', создания домашней директории и т.п.
1 Запускает программу useradd для добавления аккаунта в /etc/
+
# Конвертирует новую созданную запись '''/etc/passwd''' в файл '''LDIF'''.
passwd, создания домашней директории и т.п.
+
# Запускает команду ''ldapadd'' для добавления записи в файл '''LDIF''', который мы только что создали в директории '''LDAP'''.
2 Конвертирует новую созданную запись /etc/passwd в файл LDIF.
+
# Устанавливает пароль для пользователя.
3 Запускает команду ldapadd для добавления записи в файл LDIF,
+
 
который мы только что создали в директории LDAP.
+
Вот этот скрипт. Нумерация строк нужна только для ссылок на них – в файле их быть не должно:
4 Устанавливает пароль для пользователя.
+
 
    Вот этот скрипт. Нумерация строк нужна только для ссылок на них –
+
<source lang=bash>
в файле их быть не должно:
+
 
   1 useradd -m $1
 
   1 useradd -m $1
 
   2 grep $1 /etc/passwd > newuser.in
 
   2 grep $1 /etc/passwd > newuser.in
 
   3 grep $1 /etc/group > newgroup.in
 
   3 grep $1 /etc/group > newgroup.in
   4 /usr/share/openldap/migration/migrate_passwd.pl newuser.in >
+
   4 /usr/share/openldap/migration/migrate_passwd.pl newuser.in > newuser.ldif
  newuser.ldif
+
   5 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/ openldap/ldap_passwd -W -f newuser.ldif
   5 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/
+
   6 /usr/share/openldap/migration/migrate_group.pl newgroup.in > newgroup.ldif
  openldap/ldap_passwd -W -f newuser.ldif
+
   7 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/openldap/ldap_passwd -W -f newgroup.ldif
   6 /usr/share/openldap/migration/migrate_group.pl newgroup.in >
+
   8 ldappasswd -x -S -D “cn=admin,dc=example,dc=com” -y /etc/openldap/ldap_passwd “uid=$1,ou=users,dc=example,dc=com”
  newgroup.ldif
+
</source>
   7 ldapadd -x -D “cn=admin,dc=example,dc=com” -y /etc/
+
 
  openldap/ldap_passwd -W -f newgroup.ldif
+
Строка 1 в скрипте добавляет учетную запись пользователя на
   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 – ссылка на первый аргумент, переда-
+
копируется в нее из '''/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'''.
 +
 
 +
{{Врезка|Содержание=[[Изображение:LXF105_87_1.jpg|Рис. 3|300px]]Рис. 3. Структура каталога LDAP, используемая в учебнике.|Ширина=300px}}
 +
 
 +
===Клиентская часть ''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 и перейдите [[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.

Текущая версия на 11:09, 28 апреля 2009

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 -Dcn=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 -Dcn=admin,dc=example,dc=com” -y /etc/openldap/ldap_passwd -W -f newgroup.ldif
  8 ldappasswd -x -S -Dcn=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.

Персональные инструменты
купить
подписаться
Яндекс.Метрика