Ключевые слова:ldap, pam, auth, (найти похожие документы)
From: Артемий Евгеньевич Капитула <dalth@surw.ru.>
Newsgroups: email
Date: Mon, 18 Nov 2004 14:31:37 +0000 (UTC)
Subject: Настройка сервера LDAP и PAM_LDAP
Оригинал: http://www.surw.ru/~dalth/pam_ldap.htmlНастройка PAM_LDAP
ВАЖНОЕ ЗАМЕЧНИЕ: ВСЕ ДЕЙСТВИЯ, ОПИСАННЫЕ В ДАННОЙ СТАТЬЕ БЫЛИ
БОЛЕЕ-МЕНЕЕ ПРОВЕРЕНЫ НА ПРАКТИКЕ, НО В ЛЮБОМ СЛУЧАЕ - ВСЕ ВРЕМЯ
УСТАНОВКИ ЭТИХ НАСТРОЕК Я НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ ВАМ ИМЕТЬ ДВЕ
ЗАПАСНЫХ (Т.Е. ТЕХ, С КОТОРЫХ ВЫ НЕ РАБОТАЕТЕ В ТЕКУЩИЙ МОМЕНТ)
КОНСОЛИ С ПРАВАМИ СИСТЕМНОГО АДМИНИСТРАТОРА.
Что такое PAM_LDAP?
PAM_LDAP - это модуль для подсистемы PAM (Pluggable Authentication
Modules). NSS_LDAP - это эще один модуль, позволяющий хранить в
каталоге LDAP единую базу системной информации - пользователей, групп,
компьютеров, сервисов и т.д., которую могут совместно использовать
множество Linux-систем. Хотя существуют реализации этих модулей не
только для Linux, но и для FreeBSD, Solaris и других Unix-систем, в
этой краткой инструкции я буду рассматривать ТОЛЬКО Linux, причем на
примере своего дистрибутива Fedora Core 1 (впрочем, эти же инструкции
должны естественным образом без особых изменений пойти и на других
более-менее современных дистрибутивах). Рассматривать действия по
настройке этих модулей я стану в комплексе, не разделяя, что делается
для pam_ldap, и что для nss_ldap.
Необходимые условия
* Установленный дистрибутив Fedora Core 1
* Установленный пакет nss_ldap
* Установленный пакет openldap-servers
* Прямые руки :-)
Настройка сервера OpenLDAP
Прежде всего, необходимо выбрать suffix - фактически, это полное имя
корневого объекта вашего каталога. Обычно его связывают с доменным
именем, например для домена pupkin.com.ru оптимальнее всего
использовать следующий суффикс: dc=pupkin,dc=com,dc=ru. Кроме этого,
нам потребуется имя для администраторского эккаунта в каталоге. Это
имя получается добавлением уникального в текущей ветви дерева
идентификатора к суффиксу. Полученное значение называют rootdn, и
используя это имя, можно получить полный доступ к каталогу. Пусть в
нашем примере rootdn будет cn=sysadm,dc=pupkin,dc=com,dc=ru. теперь
укажем пароль для этой учетной записи, для чего запустим утилиту
slappasswd: slappasswd -h '{SMD5}' -s zarazamelkaya
Слово zarazamelkaya в данном случае и будет являться паролем. В
приципе, можно указать пароль и открытым текстом, но этого делать не
рекомендуется. Выданную утилитой slappasswd строку стоит записать
куда-нибудь :-)
Теперь приступаем к редактированию /etc/openldap/slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/redhat/autofs.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/misc.schema
pidfile /var/run/slapd.pid
access to attrs=userPassword by self write by * auth
access to * by peername=127.0.0.1 read by anonymous auth by users read
database ldbm
suffix "dc=pupukin,dc=com,dc=ru"
rootdn "cn=sysadm,dc=pupkin,dc=com,dc=ru"
rootpw {SMD5}hjUUf7pqdVsrpG44/Ql+hlszywY=
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
В качестве параметра для rootpw мы и указали сгенерированный хэш от
пароля первичного администратора сервера каталога. Директивы include
служат для подключения файлов схем LDAP, описывающих атрибуты и классы
объектов, хранимых в каталоге. Директивы index указывают, по каким
атрибутам нужно строить индектсы для ускорения поиска. Параметр
database определяет бакэнд для хранения базы.
Запускаем сервер:
/etc/init.d/ldap start
Создаем корневой объект каталога:
admin$ echo -e "dn: dc=pupkin,dc=com,dc=ru
objectClass: dcObject
objectClass: organization
dc: pupkin
o: Vasya Pupkin and Co. Ltd" | ldapadd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389
Проверяем, что сервер работает:
ldapsearch -x -D "cn=sysadm,dc=pupkin,dc=com,dc=ru" \
-w zarazamelkaya -s sub -b "dc=pupkin,dc=com,dc=ru" \
"(objectClass=*)"
Если ошибок нигде совершено не было, ldapsearch выдаст на стандартный
вывод описание созданого командой ldapadd объекта в формате ldiff.
Впоследствии такой ldiff-файл может быть использован для
восстановления каталога, или для создания его двойника.
Настройка PAM и NSS для использования LDAP
Для достижения нужного эффекта нам необходимо "довести до ума"
конфигурационный файл для pam_ldap (называется он /etc/ldap.conf) и
произвести настройку собственно PAM. Начинаем со второго пункта, и
запускаем authconfig (в RedHat и подобных). Активизируем использование
аутентификации в LDAP, НЕ ОТКЛЮЧАЯ ИСПОЛЬЗОВАВШИХСЯ РАНЕЕ ОПЦИЙ, иначе
начнутся проблемы. Указываем в качестве адреса сервера LDAP адрес
127.0.0.1 и в качестве basedn значение нашего suffix'а из конфигурации
сервера:
dc=pupkin,dc=com,dc=ru
На самом деле, authconfig просто исправляет три файла:
/etc/pam.d/system-auth /etc/ldap.conf и /etc/nsswitch.conf, при этом
после завершения authconfig рекомендуется проверить, чтобы содержимое
/etc/ldap.conf выглядело примерно описанным ниже образом. В принципе,
в /etc/ldap.conf есть много очень полезных комментариев и параметров,
но нам пока что они не интересны. Вот слегка измененная копия
/etc/ldap.conf с работающей системы.
host 127.0.0.1
base dc=pupkin,dc=com,dc=ru
rootbinddn cn=sysadm,dc=pupkin,dc=com,dc=ru
port 389
scope sub
pam_filter objectclass=posixAccount
pam_login_attribute uid
nss_base_passwd dc=pupkin,dc=com,dc=ru?sub?objectClass=posixAccount
nss_base_shadow dc=pupkin,dc=com,dc=ru?sub?objectClass=posixAccount
nss_base_group dc=pupkin,dc=com,dc=ru?sub?objectClass=posixGroup
ssl no
pam_password md5
Также неоходимо создать файл /etc/ldap.secret и сохранить в нем пароль
администратора каталога. Этот пароль будет использоваться для
выполнения административных функций, и не будет доступен обычным
пользователям:
# echo "zarazamelkaya" >/etc/ldap.secret
# chmod 600 /etc/ldap.secret
# chmod root:root /etc/ldap.secret
В /etc/nsswitch.conf строки, указывающие, из какого источника
программам нужно брать данные о пользователях, паролях и группах,
должны выглядеть аналогично следующему примеру:
passwd: files ldap
shadow: files ldap
group: files ldap
Настройки PAM для использования LDAP производятся путем корректного
вписывания pam_ldap.so в нужные файлы в /etc/pam.d - уточним, что
нужный файл в моем любимом дистрибутиве Fedora Core 1 только один,
зовется он /etc/pam.d/system-auth и выглядит следующим образом:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account sufficient /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_ldap.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so
Необходимо отметить, что если вы попытаетсь настроить все это
используя утилиту authconfig, в рискуете получить неработспособную в
случае отсутствия LDAP-сервера систему. Приведенный мной пример
содержимого файла /etc/pam.d/system-auth свободен от этого недостатка
- хотя, возможно, обладает другими ошибками. Тем не менее, поскольку
этот файл работает и у меня дома, и на работе, я буду считать его
подходящим. Естественно, не следует также забывать о том, что опции,
передаваемые в pam_unix.so (md5, shadow & etc) варьируются в
зависсимости от настроек вашей системы.
Регистрация пользователей
Совершив данные исправления, можно приступать к тестированию, для чего
необходимо завести пользователя. Пользователи у нас будут являться
сочетанием двух классов - nisMailAlias и posixAccount. Почему так? Да
потому, что я ленив - и данное сочетание удовлетворяет минимальным
необходимым условиям: класс nisMailAlias является STRUCTURAL (т.е.
экземпляр объекта этого класса можно породить), и требует только
наличия атрибута cn, а класс posixAccount является AUXILIARY, и
требует атрибутов cn, uidNumber, gidNumber и uid:
admin$ echo "dn: cn=vasya,dc=pupkin,dc=com,dc=ru
objectClass: nisMailAlias
objectClass: posixAccount
cn: vasya
uid: vasya
uidNumber: 1000
gidNumber: 1000
gecos: Vasiliy Pupkin
loginShell: /bin/bash
homeDirectory: /home/vasya" | ldapadd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389
admin$ echo "dn: cn=petya,dc=pupkin,dc=com,dc=ru
objectClass: nisMailAlias
objectClass: posixAccount
cn: petya
uid: petya
uidNumber: 1001
gidNumber: 1000
gecos: Petya Pupkin
loginShell: /bin/bash
homeDirectory: /home/petya" | ldapadd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389
admin$ echo "dn: cn=katya,dc=pupkin,dc=com,dc=ru
objectClass: nisMailAlias
objectClass: posixAccount
cn: katya
uid: katya
uidNumber: 1001
gidNumber: 1000
gecos: Katya Pupkina
loginShell: /usr/bin/mc
homeDirectory: /export/home/katya" | ldapadd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389
Значения атрибутов с их привязкой к идентификаторам:
uid==getenv("USER"), uidNumber==getuid(), gidNumber==getgid(),
остальные поля понятны по названию. Тэк-с, пользователей мы создали -
теперь создадим группу:
admin$ echo "dn: cn=pupkingroup,dc=pupkin,dc=com,dc=ru
objectClass: posixGroup
cn: pupkingroup
gidNumber: 1000
description: Primary group of Pupkin-COM-RU domain
memberUid: vasya
memberUid: petya
memberUid: katya" | ldapadd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389
И напоследок установим пароли для наших пользователей:
admin$ ldappasswd -x \
-D "cn=sysadm,dc=pupkin,dc=com,dc=ru"
-w zarazamelkaya
-h localhost -p 389 -s SuperParol cn=vasya,dc=pupkin,dc=com,dc=ru
Вот и все, осталось проверить, что пользователь vasya может
логиниться. По крайней мере, у меня он логинился с паролем SuperParol
:-) Есть один немаловажный аспект, в данной статье не рассмотреный -
это настройки безопасности и контроля доступа сервера LDAP - но это
уже тема для другой статьи.
Если в /etc/ldap.conf мы пишем
pam_filter objectclass=posixAccount
то указывать потом тот-же фильтр в строках
nss_base_passwd и nss_base_shadow
нет смысла -- строка из pam_filter добавляется к фильтру. Получается что-то вроде
(&(objectClass=posixAccount)(uid=vasya)(objectClass=posixAccount)) - хуже не будет, но и толку особого нет.
