Аутентификация в сети. NIS и NIS+. LDAP и PAM

База аутентификации NIS+

Несмотря на схожесть названий, NIS и NIS+ не имеют ничего общего, кроме похожих имен и функций. Организованы они по-разному. В данной лекции подробности настройки NIS+ не рассматриваются, ввиду малой распространенности таких решений в России. Основное применение NIS+ – крупные UNIX-сети больших компаний.

По сравнению с NIS, база NIS+ обладает лучшей безопасностью данных, более удобной системой хранения, и другим механизмом репликации баз данных по сети. Структуры баз данных, которые в NIS называются картами, в NIS+ называются таблицами.

Всего в NIS+ определено 16 таблиц:

Hosts, Bootparams, Password, Cred, Group, Netgroup, Aliases (псевдонимы компьютеров в домене, к почте не относятся), Timezone, Networks, Netmasks, Ethers, Services, Protocols, RPC, Auto_Home, Auto_master.

Для управления NIS+ следует использовать команды nisbladm (модификация таблиц NIS+), nisgrep (поиск в них), niscat (вывод таблицы NIS+).

Управление NIS+ доступно из Solaris Management Console.

В файле /etc/nsswitch.conf для указания того, что некую проверку следует производить в NIS+, служит ключевое слово nisplus.

Внимание! Нельзя в /etc/nsswitch.conf писать nis+ вместо nisplus!

Файл /etc/nsswitch.conf может выглядеть, например, так:

# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis

Ключевое слово [NOTFOUND=return] в записи hosts предписывает клиенту NIS вернуться, если нужный элемент не может быть найден в базе данных NIS или DNS.

Работа над ошибками

Если при работе NIS возникают непредвиденные ошибки (например, не происходит передача карт NIS с главного сервера на подчиненные), следует изучить файлы протоколов /var/yp/ypxfr.log на всех серверах. Если такого файла не существует, его надо создать и убедиться, что пользователь, от имени которого работают службы NIS, имеет право записи в этот файл.

Если оказывается, что сменить пароль пользователя невозможно, это может быть вызвано как недоступностью карт для демона yppasswdd, так и тем, что такой демон вовсе не запущен на главном сервере NIS. Проверяйте, какой сервер NIS каждый из компьютеров считает главным, с помощью команды

ypwhich

Альтернатива NIS и NIS+ – LDAP. Подсистема PAM

Сравнительно свежей тенденцией в мире UNIX и сетей вообще является использование протокола LDAP (lightweight directory access protocol – облегченный протокол доступа к каталогу, где каталог понимается как хранилище разнообразной информации, в том числе имен пользователей, паролей и т.п.) и соответствующих служб – демонов ldap для обеспечения доступа к информации о пользователях, компьютерах и их свойствах. В отличие от NIS, LDAP позволяет хранить информацию совершенно универсальным способом (в виде дерева объектов и атрибутов) и сейчас поддерживается основными игроками компьютерной индустрии.

Подробнее о протоколе LDAP можно узнать на веб-сайте www.openldap.com, откуда можно еще и загрузить свежую версию бесплатного ldap-сервера.

Таким образом, использование NIS и NIS+ не является сейчас повсеместным и не представляет собой наилучшую альтернативу простой синхронизации файлов из /etc на всех компьютерах сети с помощью rsync. Дело в том, что протокол NIS недостаточно защищен, а NIS+ – довольно сложен в настройке. Поэтому, если вы планируете использовать централизованную аутентификацию и авторизацию в сетях UNIX, имеет смысл обратить внимание на LDAP, и, кроме того, не забывать о возможностях PAM: ведь с помощью этой подсистемы можно производить аутентификацию и авторизацию с использованием любых источников – от файлов passwd до контроллеров домена Windows NT/2000.

PAM

Перед тем, как говорить об аутентификации, следовало бы определиться с тем, что это такое. Слово "аутентификация" происходит от слова "аутентичность", что означает подлинность, соответствие подлинному, истинному. Иногда "аутентичность" расшифровывают как "соответствие самому себе" (если вы – философ, такая формулировка может вам понравиться).

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

За процедурой аутентификации часто следует авторизация – предоставление пользователю определенных прав доступа к ресурсу. Разным пользователям (и разным группам пользователей) назначаются разные права.

Распространенные схемы аутентификации

В системах UNIX, как правило, выполняется стандартная аутентификация, с использованием файла паролей ( /etc/passwd, /etc/shadow ). Для централизованной аутентификации на нескольких компьютерах в сети были разработаны разные схемы, связанные с централизованным хранением базы данных пользователей и паролей.

Конечно, надо вспомнить NIS и NIS+ (см. "Резервное копирование и восстановление" ), если мы говорим о централизации. Кроме этого, аутентификация может происходить по протоколу TACACS (широко распространен в серверах удаленного доступа Cisco) или RADIUS (в серверах удаленного доступа Nortel). Бывают и другие возможности аутентификации. В далеком прошлом не было единого механизма, который давал бы общий интерфейс аутентификации для любой сетевой службы и любого способа аутентификации.

Структура подсистемы PAM – присоединяемых модулей аутентификации

Новая модель аутентификации – присоединяемые модули аутентификации (PAM, pluggable authentication modules) была предложена в 1995 году сотрудниками SunSoft Самаром (V. Samar) и Шемерсом (R. Schemers). Эта модель предполагала, что любое приложение будет работать со стандартным интерфейсом аутентификации, а механизм аутентификации может быть различным, так как для аутентификации в разных базах данных пользователей (NIS, TACACS, файлы /etc/passwd и /etc/shadow, контроллер домена Microsoft Windows и т.п.). Более того, предполагалось, что системный администратор должен иметь возможность выбрать, какой вид аутентификации будет использоваться в системе по умолчанию и/или для каждой из служб в отдельности: от ввода текстового пароля до биометрической проверки и использования смарт-карт.

Возможность индивидуальной настройки аутентификации для каждого из приложений, требующих ее, – это большой шаг вперед к гибкой настройке системы. Например, все базовые службы можно аутентифицировать по умолчанию, через ввод пароля, а что-то нестандартное или особо секретное (доступ к настройкам фильтра пакетов, например) – специальным образом.

В PAM с каждым приложением можно связать не один, а несколько механизмов аутентификации, например, потребовать от пользователей аутентифицироваться и через Kerberos, и через RSA.

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

Архитектура PAM модульная и позволяет добавить любой модуль с поддержкой какого угодно нового алгоритма аутентификации, но при этом ради обратной совместимости PAM API поддерживает ранее существовавшие вызовы подпрограмм аутентификации.

Добавление PAM в Solaris не означает, что системный администратор обязан специальным образом настраивать систему аутентификации, PAM лишь предоставляет такую возможность. Если нет желания переделывать настройки по умолчанию, то для пользователей все останется, как раньше. А системный администратор будет помнить, что каталог /etc/ pam.d, в котором хранятся настройки PAM, трогать не следует.

Модули PAM

Механизм аутентификации PAM основан на модулях аутентификации. Сейчас можно уже называть его отраслевым стандартом, так как PAM поддерживается в Linux, FreeBSD, Solaris и HP-UX, а также в ряде других менее распространенных систем UNIX.

Рис. 8.1. Архитектура PAM

Со стороны приложения PAM предоставляет API для обращения к функциям аутентификации.

Программа ( login, su, ftp, httpd и т.п.). вызывает функцию PAM API в ситуации, требующей провести аутентификацию. С другой стороны (со стороны модуля аутентифиации), PAM располагает интерфейсом SPI (Service Provider Interface), через который вызов API транслируется к источнику аутентификации (файлу /etc/passwd, серверу TACACS и т.п.).

API является общим для всех программ, а SPI содержит по одному модулю на каждый вариант аутентификации (один – через /etc/passwd, другой – через Kerberos и т.п.)

С помощью PAM системный администратор может установить свой способ аутентификации для любой сетевой службы. Более того, спектр способов весьма широк. Наиболее впечатляющей, на мой взгляд, является возможность аутентификации с использованием базы данных о пользователях любого домена WindowsNT или Windows2000.

Самой важной возможностью PAM является гибкость настройки аутентификации. Системный администратор может указать любой способ аутентификации для любой программы. Правда, важно, чтобы программа поддерживала аутентификацию через PAM. Например, может оказаться, что web-сервер не умеет работать с PAM. Однако, Apache умеет это делать, хотя для этого требуется загружать отдельный модуль Apache.

В Solaris настройки PAM хранятся в файле /etc/pam.conf. Во многих других системах UNIX также допускается хранение настроек в каталоге /etc/pam.d/. Если такой каталог существует, то подпрограммы PAM игнорируют содержимое /etc/pam.conf.

Аутентификацию через PAM используют программы login, passwd, su, rlogind, rshd, telnetd, ftpd, rpc.rexd, uucpd, init, sac, cron, ppp, dtsession, ssh и ttymon. Программа dtlogin, которая является службой входа в систему для графической среды CDE, и программа gdm (ее аналог для GNOME) тоже применяют PAM.

Модули PAM могут располагаться в любых каталогах, однако, негласное правило требует, чтобы файл имел имя, начинающееся с pam, pam_modulename.so.x, например, и хранился в подкаталогах каталога usr/ lib/security/.

Функции модулей pam

Модуль PAM представляет собой динамически присоединяемый модуль (файл с расширением .so), т.е. фактически – разделяемую библиотеку.

С точки зрения PAM, аутентификация состоит из нескольких независимых задач:

• управление учетными записями;
• управление аутентификацией;
• управление паролями;
• управление сессиями.

Для идентификации этих задач в конфигурационном файле используются аббревиатуры account, auth, password, session.

Решение одной или нескольких из этих задач требуется при доступе пользователя к ресурсу.

Какие цели у модуля, решающего ту или иную задачу?

1. account – описывает службу проверки учетной записи, которая отвечает на вопросы: "есть ли такая запись и не истек ли срок действия пароля?", "имеет ли пользователь право доступа к запрошенному ресурсу?"
2. authentication – описывает службу проверки идентичности пользователя. Эта служба реализована посредством диалога между пользователем и программой аутентификации: "как тебя зовут и какой у тебя пароль?". Здесь пользователь обязан сообщить соответствующие друг другу имя и пароль (или иное подтверждение того, что пользователь именно тот, за кого он себя выдает).

   Некоторые методы аутентификации (например, смарт-карты) не предполагают диалога, идетнификацию выполняет специальная аппаратура, которая общается с написанным специально для нее модулем PAM. В этом проявляется гибкость PAM: старый добрый login может не задавать вопросов "login:", "password:".

   Не меняя программ, требующих аутентификацию, PAM позволяет аутентифицировать пользователя любым способом, который изберет системный администратор. Может быть сейчас он еще и не знает, что он выберет через год, а кто-то уже пишет PAM-модуль для своей аппаратуры опознавания сотрудника по запаху.
3. password – описывает службу изменения пароля; такая служба должна быть тесно связана со службой проверки учетной записи. Например, по истечении срока действия пароля система требует у пользователя новый пароль.
4. session – описывает работы, которые должны быть выполнены до того, как ресурс будет предоставлен, или после того, как он будет освобожден (например, после разрыва соединения между программой-клиентом и вызванной им службой-сервером). Скажем, это может быть протоколирование начала и конца соединения, монтирование домашнего каталога пользователя и т.п..