Использование распределённого сервера каталогов (РСК) для хранения
аутентификационной информации является очень распространённой практикой
применения технологии LDAP. В UNIX аутентификация на основе LDAP пришла
на cмену устаревшим и небезопасным сервисам NIS (Network Information
Services), для Windows же сейчас (к сожалению или к счастью) нет
альтернатив всеведущему и всемогущему каталогу Active Directory.
Поскольку статья ориентирована в первую очередь на администраторов
UNIX-систем, здесь не будет рассматриваться механизм аутентификации в
AD. Об этом уже написано немало книг, так что информацию на эту тему
всегда можно найти в сети и на прилавках книжных магазинов.
Поговорим об авторизации с использованием РСК в качестве источника даных аутентификации в UNIX на примере ОС Linux.
В Linux поиск информации о пользовательских аккаунтах осуществляется в
абстрактных «базах данных» passwd, groups и shadow, доступ к которым
предоставляет так называемый Переключатель Сервисов Имён (Name Service
Switch), являющийся интерфейсной прослойкой между пользовательскими
приложениями и реальными формами представления данных об обьектах. Таким
образом, NSS позволяет абстрагироваться от конкретного представления
данных и берёт на себя взаимодействие с необходимыми службами по
понятным им протколам. Собственно авторизацию пользователя в системе
обеспечивает служба PAM (Подключаемые Модули Аутентификации), которая в
соответствии со своим названием имеет модульную архитектуру, позволяющую
максимально гибко проектировать процесс аутентификации, объединяя
модули по принципу стэка.
Компания PADL.com (http://www.padl.com),
специализирующаяся на коммерческих и OpenSource-решениях на базе РСК,
разработала специальные модули служб NSS и PAM для обеспечения
возможности использования СК в качестве общесистемной базы аккаунтов в
*nix-подобных операционных системах. Эти модули, называющиеся nss_ldap и
pam_ldap, реализуют расширения соответствующих служб UNIX, позволяя им
взаимодействовать с РСК. Модули, реализованные в виде библиотек с
разделяемым кодом, могут работать в ОС Linux, IBM AIX, FreeBSD, SUN
Solaris (в последней, правда, чаще всего используется собственная
обвязка NSS-NetscapeLDAP, поскольку у Sun есть интегрированный в Solaris
СК - небезызвестный SUN Java System Directory Server).
Итак, после небольшого теоретического вступления перейдём
непосредственно к практической части интеграции СК и системных служб
аутентификации. Настройки NSS доступны в файле /etc/nsswitch.conf, где
определяется соответствие между виртуальной базой данных и реальным
хранилищем. Формат данного конфигурационного файла отлично описан в
документе man nsswitch.conf, нас же интересует то, как организуется
связка между nsswitch и СК для использования последнего в качестве
источника данных виртуальных баз passwd, group и shadow. Для этого
необходимо, чтобы определения этих баз в nsswitch.conf выглядели след.
образом:
passwd: files ldap
shadow: files ldap
group: files ldap
Здесь указывается, что служба NSS в поисках учётной записи будет сначала
просматривать файлы /etc/passwd, /etc/group и /etc/shadow
соответственно, а если не найдёт её там, обратится к РСК, используя
разработанный PADL.com модуль libnss_ldap.so.X, где X- ни что иное, как
minor (средняя) часть версии используемой в системе библиотеки glibc.
Очевидно, что для реализации данного механизма NSS нужно в свою очередь
знать, что и как ей следует искать в РСК, а для этого используется ещё
один конфигурационный файл, /etc/ldap.conf, в котором и указываются все
необходимые параметры. Пример такого файла, реально используемого у меня
на сервере авторизации в домашней сети, приводится ниже:
uri ldap://localhost:389
base ou=home,o=Moscow,c=ru
rootbinddn cn=authd,ou=System,ou=home,o=Moscow,c=ru
scope sub
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute gid
pam_password md5
nss_base_passwd ou=Groups,ou=home,o=Moscow,c=ru?sub
nss_base_shadow ou=Groups,ou=home,o=Moscow,c=ru?sub
nss_base_group ou=Groups,ou=home,o=Moscow,c=ru?one
ssl no
tls_cacertdir /etc/openldap/cacerts
Ниже даётся описание используемых параметров :
- uri – так называемый Universal Resource Identifier (универсальный идентификатор ресурса, аналог URL в протоколе HTTP) в формате:
<Метод LDAP-доступа>://<ХОСТ>:<ПОРТ>(<ПРОБЕЛЬНЫЕ
СИМВОЛЫ><Метод LDAP-доступа1>://<ХОСТ1>:<ПОРТ1>)*,
где -
- Метод LDAP-доступа указывает на использование LDAP-протокола обмена с сервером и на конкретные особенности обмена данными:
- ldapi - по механизму IPC (межпроцессного взаимодействия), т.е. через специальный UNIX-сокет;
- ldaps - через TCP/IP сокет по инициируемому на этапе соединения шифрованному каналу через выделенный альтернативный порт;
- ldap - через TCP/IP сокет, либо без шифрования, либо с
использованием механизма StartTLS, позволяющего уже после создания
соединения на стандартный порт (389) договориться с сервером о создании
шифрованного канала
- ХОСТ - IP-адрес или DNS-имя используемого сервера LDAP. Вознамерясь
указать здесь DNS-имя сервера, непременно убедитесь прежде в том, что
для него может быть найдено соответствие в базах dns и/или hosts
(виртуальные базы из уже знакомого нам файла nsswitch.conf) без использования ldap,
иначе Вы столкнётесь с клинчем наподобие загадки о курице и яйце,
безуспешно решая которую Ваша система неминуемо придёт в
неработоспособное состояние!
- ПОРТ - собственно порт обмена данными с сервером - для ldap и ldapi обычно используется 389-й порт, а для ldaps - 636-й
- base – суффикс («корень» или «база») используемого СК;
- rootbinddn
– отличительное имя (DN) пользователя, с правами которого NSS
подключается к серверу LDAP, если к ней обращается процесс с EUID=0,
т.е. процесс с правами администратора системы (отсюда и root в имени
параметра. А Вы о чём подумали?);
- scope
– глубина просмотра дерева каталога, которая будет использоваться, если
она не указана явно в параметрах nss_base_VBD (см.ниже). Параметр scope может принимать следующие значения:
- base - нулевой уровень вложенности: в область поиска попадает только запись собственно базы поиска;
- one - первый уровень вложенности: сюда попадает запись для DN базы поиска и все записи, нижележащие относительно базы;
- sub - все уровни вложенности: то же, что one, но в поиске будут участвовать все уровни ниже базы поиска;
- pam_filter
– первая из настроек, относящихся не к NSS, а к службе аутентификации
PAM, задаёт фильтр, по которому должен осуществляться поиск
пользовательских учётных записей;
- pam_login_attribute
– атрибут записи в СК, по символьному значению которого будет
осуществляться поиск учётной записи пользователя по имени (логину),
переданному команде авторизации;
- pam_member_attribute
- атрибут записи в СК, значение которого извлекается из записи,
найденной по значению атрибута gidNumber учётной записи пользователя в
СК и используется как символическое имя группы, к которой он
принадлежит;
- pam_password
– тип шифрования, который будет использоваться при создании новых
паролей учётных записей СК (в данном случае используется необратимое
хеширование по методу md5);
- nss_base_passwd
– область поиска данных для виртуальной базы passwd. Указывается в
формате: базовыйDN[?глубина], где базовыйDN – Distinguished Name
объекта, с которого следует начинать поиск, а глубина – по смыслу тоже,
что в описании параметра scope (base|one|sub), о котором рассказывалось
выше и который используется в качестве значения по умолчанию, если
«глубина» не указана;
- nss_base_group – область поиска данных для виртуальной базы group. Интерпретация значения данного параметра – см. nss_base_passwd;
- nss_base_shadow – область поиска данных для виртуальной базы shadow. Интерпретация значения данного параметра – см. nss_base_passwd;
- ssl
– булев (двоичный) переключатель, может принимать булевы значения
yes,no,on,off,1,0. Указывает на необходимость использования защищённого
(шифрованного) соединения между клиентом (службами NSS/PAM) и СК;
- tls_cacertdir
– абсолютный путь до каталога, в котором содержатся сертификаты
авторизованных центров сертификации CA, один из которых поставил подпись
на сертификате нашего сервера LDAP. Кстати, если у Вас используется
параноидальная схема, при которой доступ к СК предоставляется только
доверенным клиентам, то клиентский сертификат также должен быть заверен
центром CA, сертификат коего находится в указанном каталоге.
Обратите особо пристальное внимание на то, что в опции uri
можно указать несколько путей к LDAP-серверам. Работает это следующим
образом: при необходимости запросить информацию РСК (при использовании
кеширующего демона NSCD для NSS
такая необходимость возникает не так уж и часто, но об этом мы расскажем
в заключительной части данной статьи) , сервисы PAM и NSS
последовательно перебирают указатели ресурсов до первого успешного
соединения, так что если хост по первой ссылке оказывается недоступен,
производится обращение ко второму, если не отвечает и второй,
запрашивается третий. И так далее. Пользу от применения подобного
подхода трудно переоценить, поскольку именно в "многозначности" опции
uri заложена потенциальная возможность построения отказоустойчивой
распределённой системы аутентификации.
Теперь займёмся настройкой службы PAM. Делается это либо путём редактирования подключаемых файлов в каталоге /etc/pam.d
– здесь их приходится по одному на каждую программу, запрашивающую
службу авторизации, либо через /etc/pam.conf, отличающийся от /etc/pam.d
только тем, что здесь настройки всех программ свалены в один "плоский"
файл. Следует отметить, что при наличии каталога /etc/pam.d файл
/etc/pam.conf будет проигнорирован, даже если он присутствует в системе.
К счастью, сейчас уже на большинстве UNIX-систем, за исключением разве
что Solaris, используется именно каталог-ориентированная структура
хранения настроек PAM. Кстати, если у Вас один из дистрибутивов, ведущих
свою родословную от RedHat Linux и включающих инструмент под названием authconfig,
можете считать, что Вам крупно повезло, потому что здесь аутентификация
посредством LDAP настраивается буквально в один клик мышкой/щелчок
клавиатуры. В authconfig вам всего лишь необходимо перейти в раздел
Аутентификация (Authentification) и активировать пункт «Исп. LDAP» (Use LDAP), после чего указать необходимые параметры соединения с LDAP-сервером (он же СК, он же РСК 
). Пользователям других дистрибутивов Linux и прочих *nix-систем,
придётся всё-таки приложить определённые усилия для разруливания
ситуации, например, настроить конфиги PAM вручную.
Файлы настройки PAM делятся на секции, каждая из которых раскрывает те
или иные идентифицируемые по префиксу строки аспекты авторизации с
использованием той программы, к которой файл относится. Определены
следующие префиксы (они же «аспекты авторизации»):
- account
– Проверка актуальности учётной записи пользователя, легальности его
работы в системе. Включает в себя, например, проверку на истечение
периода действия пароля, на блокировку пользователя (администратор
сервера может запретить данному пользователю вход в систему, если тот
нарушил правила работы или... уехал в отпуск на месяц и просил не
беспокоить до увольнения);
- auth
– собственно процесс аутентификации, когда пользователю необходимо
сначала представиться, а затем предоставить убедительные доказательства
того, что он именно тот, за кого себя выдаёт. account и auth я бы
выделил условно в «контрольные функции авторизации», поскольку они
занимаются проверками легитимности субъекта, запрашивающего у системы
полномочия;
- password
– всё, что связано со сменой аутентификационных данных. Классическим
примером является команда passwd, позволяющая пользователю сменить
пароль на новый, если он предоставит правильный старый пароль;
- session
– в полном соответствии со своим названием устанавливает параметры
окружения для новой сессии пользователя, такие, как установка переменных
окружения, запуск назначенной оболочки и т.д.
Таким образом, password и session
условно можно отнести к сервисным функциям авторизации, поскольку они
обслуживают пользователя, уже аутентифицированного в стэке модулей,
формируемом секцией auth.
За префиксом, идентифицирующим секцию, следует инструкция, которая
определяет,что следует делать PAM, если модуль, вызываемый в данной
строке, сообщит о своём фиаско (например, при попытке установки нового
пароля пользователь не сможет правильно назвать свой старый пароль).
Инструкция может быть представлена как в простом формате (requisite,required,sufficient,optional),
так и в сложном (в квадратных скобках указываются пары опция=значение).
После инструкции следует путь к подгружаемому в стек модулю PAM,
замыкающими в строке являются параметры, передаваемые модулю. Мы не
станем вдаваться в подробности того, какой смысл имеют те или иные
значения «инструкции» или какие параметры принимают стандартные модули
PAM, но сразу перейдём к практической реализации включения модуля pam_ldap в стэк.
Для того, чтобы настроить системы на аутентификацию с использованием
pam_ldap, вам не нужно править файл настроек каждого
PAM-ориентированного приложения - достаточно отредактировать файл /etc/pam.d/system-auth,
в котором содержится универсальный стек модулей, представляющий собой
обязательный минимум авторизации. Место модуля pam_ldap в этом
«минимальном» стэке – за модулем pam_unix, поэтому каждая из
представленных ниже строк должна быть вставлена сразу после строки,
указывающей на подключение pam_unix.so соответственно идентификатору
секции, которой она принадлежит. Итак, вот эти строки:
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
session optional /lib/security/$ISA/pam_ldap.so
Здесь путь к модулю pam_ldap.so показан условно, потому что в Вашем
конкретном случае он может и не совпадать с указанным в моём примере. На
самом деле все модули PAM, и уж тем паче -стандартные, к числу которых
pam_ldap уже давно и бесспорно относится, находятся обычно в одном
каталоге (что становится очевидным после поверхностного изучения
содержимого файла system-auth), поэтому Вы можете смело «тиражировать»
тот путь, который указан для pam_unix.so и всех прочих модулей, уже
присутствующих в стеке, и для pam_ldap.so.
Результирующий файл system-auth на системе Linux Fedora 6 выглядит следующим образом:
#%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 required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password required /lib/security/$ISA/pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 retry=3 enforce=users
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
Недостатком данной схемы является то, что при попытке смены пароля, он
будет запрошен у вас дважды: сначала модулем pam_cracklib.so, а затем -
pam_passwdqc.so, который по невыясненным причинам столь странным
образом реагирует на присутствие pam_ldap.so в стэке.
ПРИМЕЧАНИЕ: pam_passwdqc
- это PAM модуль для проверки качества паролей во время их смены. Кроме
проверки часто используемых паролей, он предоставляет поддержку
парольных фраз и может генерировать случайные пароли.
Для того, чтобы избавиться от необходимости четырёхкратного ввода одного
и того же пароля, исправьте строку, подключающую pam_passwdqc таким
образом, чтобы данному модулю передавался параметр use_authtok,
позволяющий передавать ему пароль, полученный на предыдущем этапе от
pam_cracklib, например:
password required /lib/security/$ISA/pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 retry=3 enforce=users use_authtok
На этом настройку аутентификации в UNIX с использованием СК можно считать благополучно завершённой.
Источник: http://asplinux.net/node/3536 |
