Меню

Настройка ldap сервера opensuse



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

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров) Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров) Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

то все вхождения $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. В конце концов я создал такой файл:

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

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

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

Вы должны дважды ввести ваш пароль, и оба раза сделать это правильно; в конечном итоге вы получите домашнюю директорию /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:

Эти строки велят резольверу сперва посмотреть в локальных файлах (то есть в /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. Главные строки здесь –

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

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

Это обертки вокруг библиотек функций, а именно 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 он выглядит так:

Первая строка вызывает модуль 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, чтобы узнать, откуда ее монтировать».

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

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

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

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

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

Если вы решили использовать Automounter, убедитесь, что у вас в /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). Я подкорректировал следующие три строки:

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

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

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

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

Источник

[Ubuntu][openSuSE] LDAP

Есть сервер LDAP, установленный на openSuSE 12.1. В качестве ОС на клиентских машинах используется тот же openSuSE 12.1 и Ubuntu 11.10. Настройка авторизации через LDAP пользователей на клиентских openSuSE прошла легко и заработала стабильно. А вот с Ubuntu проблемы, почитал кучу HOWTO, перепробовал кучу вариантов, но толку ноль. Может кто подскажет решение данного вопроса для Ubuntu 11.10? Данные по LDAP Адрес: ldap.example.local Версия: 3 Шифрование: выключено Пользователи: ou=people,dc=example,dc=local Пароли: ou=people,dc=example,dc=local Группы: ou=group,dc=example,dc=local

И конечно, с убунту всегда только одна проблема, о ней все знают и поэтому пояснять, в чем именно она заключается не нужно — пехота телепатов уже на марше, они придут и все вам починят. Скоро. Обязательно.

в данном случае, ответ очевиден, если не чинать по диагонали — настройка авторизации. вообще, по логам LDAP Ubuntu даже не пытается опросить его.

Видимо вы свою привычку читать по диагонали (кучу howto) переносите на окружающих.

Ну раз вам все очевидно вот сами и чините. А нормальные люди, пишут, что сделали, пишут как проверяли и пишут, почему думают, что что-то работает неправильно. И к этому прикладывают логи с клиента и сервера.

служба (демон) то хоть запущена нужная на убунту?

На данный момент остановился, что самое безопасное и не отрубает вообще авторизацию, это ответы при установке

sudo apt-get install libpam-ldap

Спросил адрес, DN и о необходимости паролей. При попытке авторизации пользователя с LDAP в /var/log/syslog кидает

lightdm: pam_ldap: ldap_simple_bind Can’t contact LDAP server

Хотя сервер жив и на ldapsearch с это машины отзывается.Где вообще живут конфиги клиента LDAP?

P.S. Прошу прощения за аггро, просто уже крыша потихоньку едит от тупости Убунты.

lightdm: pam_ldap: ldap_simple_bind Can’t contact LDAP server

Источник

Читайте также:  Ntp настройка server 2012

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

Adblock
detector