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

Службы имен

В любой сети всегда возникает вопрос централизованного хранения информации о пользователях и компьютерах. Такого рода информация включает в себя:

Помимо этих основных элементов, удобно централизованно хранить не только имена и пароли, но и все остальные свойства существующих в сети объектов.

Схема работы NIS построена по принципу многих клиентов и нескольких серверов. В домене NIS существуют один главный и несколько подчиненных серверов, но клиенты не различают главный и подчиненный серверы. Поскольку в сети NIS могут быть разные системы, следует придерживаться стандартной схемы, при которой в каждом сегменте сети есть по крайней мере один сервер NIS, для того, чтобы клиенты могли отправить ему широковещательный запрос. Однако в Solaris это не требуется, и если вся сеть построена на Solaris (этих принципов также придерживаются многие Linux-системы), то это требование не является обязательным. Впрочем, в любом случае наличие "своего" сервера NIS в сегменте сети улучшит производительность.

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

В то же время в пределах домена NIS могут быть выделены так называемые сетевые группы, логически объединяющие некоторые компьютеры и пользователей. Сетевые группы описываются файлом /etc/netgroup. Этот файл, наряду с /etc/passwd и /etc/group, является одним из тех, что делаются общедоступными и централизованными в сети NIS.

Информация о компьютерах, пользователях, группах, сетевых группах и т.п. разделяется между компьютерами в сети посредством создания из текстовых файлов /etc/passwd, /etc/netgroup и ряда других так называемых карт NIS. Карта NIS – это хэшированная база данных, которую использует сервер NIS для ответа на запросы клиентов.

Для превращения файлов типа /etc/passwd в карту NIS требуется программа ypmake. Программы, связанные с NIS, имеют имена, начинающиеся с yp, поскольку в момент создания NIS носила название Sun Yellow Pages, но название пришлось изменить, поскольку словосочетание Yellow Pages оказалось зарегистрированной маркой другой компании. На именовании программ это не отразилось. Программа ypmake не изменяет исходный файл, она лишь генерирует на его основе новый файл-карту NIS.

На основе некоторых системных файлов из подлежащих разделению через NIS, например, passwd, потребуется сгенерировать две карты, так как хэширование базы данных можно осуществить только по одному ключу, а поиск в карте, возможно, потребуется производить по нескольким ключам. В случае passwd это именно так – надо искать и UID по имени пользователя, и имя пользователя по UID. Поэтому генерируются две карты – passwd.byname и passwd.byuid.

Запуск сервисов NIS на компьютере осуществляется командой /usr/lib/netsvc/yp/ypstart, а их остановка – командой /usr/lib/netsvc/yp/ypstop.

Ниже рассказано, какие именно демоны запускаются на серверах и клиентах NIS, в том числе и при выполнении команды /usr/lib/netsvc/yp/ypstart.

Узнать о том, к какому домену причисляет себя компьютер, можно командой

domainname

Если эта команда сообщает, что компьютер не входит в домен NIS, ввести компьютер в домен можно командой domainname имя_домена_NIS, после чего следует проверить наличие и создать при необходимости файл /etc/defaultdomain и каталог /var/yp/binding/имя_домена_NIS.

В каталоге /etc/ могут быть заготовки файлов nsswitch.conf для разных конфигураций сети. Когда вы просто копируете /etc/nsswitch.nis в /etc/nsswitch.conf, не забудьте о том, что если вы желаете использовать DNS для поиска адресов компьютеров в сети, следует исправить строку, определяющую порядок использования служб имен для поиска адресов компьютеров, так, чтобы dns предшествовало nis:

hosts: dns nis files

Для запрещения загрузки служб NIS при старте системы достаточно удалить файл /etc/defaultdomain.

В каталоге /var/yp может находиться файл makefile или Makefile для автоматизированной модификации настроек NIS и распространения карт по сети. Если он есть, имеет смысл изучить его и пользоваться, при необходимости, командой make для выполнения описанных в нем действий.

Еще немного о сетевых группах

Для удобства администрирования домена NIS следует применять сетевые группы. Формат записей в файле /etc/netgroup весьма прост:

имя_группы список_участников

В качестве списка участников принимаются имена членов группы, разделенные пробелами. Член группы – это либо имя другой сетевой группы, либо конструкция вида

(имя_компьютера, имя_пользователя, имя_домена_NIS).

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

(moon, ,columbia)

означает "любой пользователь компьютера moon в домене NIS columbia". Один компьютер может входить в несколько доменов NIS. Сетевые группы удобно использовать для назначения прав доступа к экспортируемым файловым системам NFS в командах share файла /etc/dfs/dfstab.

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

Сервер NIS хранит всю информацию о доменах NIS в подкаталогах каталога /var/yp. На главном сервере NIS должны быть запущены процессы ypserv (он отвечает на запросы клиентов), ypxfrd (обслуживает запросы от подчиненных серверов NIS для репликации информации), yppasswdd (демон изменения пароля пользователя).

Настройка главного сервера NIS

Для настройки следует выполнить следующие действия:

В Solaris компьютер автоматически настроится на работу с NIS, если будет найден файл /etc/defaultdomain. Эту работу выполнит программа ypstart, которая при старте системы проверяет, установлено ли имя домена в этом файле.

Демон ypserv запускается автоматически, если соблюдаются все следующие условия:

Демон ypbind запускается автоматически, если соблюдаются все следующие условия:

Серверы NIS одновременно являются и клиентами NIS, поэтому кроме серверных демонов на них запускается и клиентский демон ypbind, который посылает запросы демону ypserv. По умолчанию демон ypbind пытается найти в сети сервер NIS своего домена, рассылая широковещательный запрос. Чтобы данный компьютер использовал строго определенный сервер NIS для получения информации либо в случае, если сервер NIS находится в другом сегменте сети и широковещательный запрос до него не может дойти через маршрутизатор, следует запускать ypbind без ключа broadcast. Для настройки клиента для работы с определенным сервером NIS следует использовать команду ypset, а для настройки клиента NIS в целом применяется ypinit с ключом с. Поэтому обе эти задачи вместе решаются так:

ypinit –c имя_сервера
ypset имя_сервера

Это настраивает запуск ypbind так, чтобы не происходило поиска сервера NIS в сети. В таком случае на клиенте NIS обязательно должен быть минимальный файл /etc/hosts, чтобы при запуске ypbind была возможность обратиться хотя бы к серверу NIS по имени.

Для изменения сценария запуска сервера NIS в Solaris следует модифицировать файл /etc/init.d/inetinit.

В Solaris 10 и более свежих версиях имеет смысл использовать подсистему SMF для настройки и управления NIS, об SMF более подробно рассказано в лекции 13.

Настройка подчиненных серверов NIS

Настройка подчиненного сервера NIS выполняется всегда только после настройки главного. Отличие в этих настройках невелико, так как состоит только в том, что надо программе ypinit передать ключ –s (slave) вместо –m. Разумеется, инспектировать локальные копии файлов passwd и прочих на подчиненном сервере не требуется, ибо его задача – только принимать реплицированные карты NIS с главного сервера. Итак, для настройки подчиненного сервера следует:

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

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

Клиент не должен абсолютно во всем полагаться на сервер NIS. Следует иметь локальные файлы /etc/passwd, /etc/group и /etc/hosts. В файле passwd должны быть указаны основные предопределенные пользователи и, возможно, личная учетная запись системного администратора для экстренных случаев.

Помните о необходимости проверить порядок опроса служб имен (вначале NIS, затем локальные файлы) в /etc/nsswitch.conf. При переходе от аутентификации через локальные файлы к NIS или обратно не забывайте изменять файл /etc/nsswitch.conf в соответствии с принятым решением о схеме аутентификации.

NIS: полезные программы

Некоторые утилиты помогают в администрировании NIS:

База аутентификации 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+ (см. лекцию 11), если мы говорим о централизации. Кроме этого, аутентификация может происходить по протоколу 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.

Со стороны приложения 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.

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

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

Настройка доступа к некоторым службам через PAM

Конфигурационный файл /etc/pam.conf определяет соответствие между приложением и PAM-модулями, которые выполняют аутентификацию.

При обращении приложения к PAM для аутентификации происходит инициализация соединения приложения с PAM API. При этом читается файл конфигурации /etc/pam.conf.

Файл конфигурации содержат список модулей PAM, которые будут использоваться для аутентификации. Рассмотрим файл конфигурации /etc/pam.conf:

#
#ident "@(#)pam.conf 1.20 02/01/23 SMI"
#
# Copyright 1996-2002 Sun Microsystems, Inc. All rights
reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_auth.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for
authenctication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_auth.so.1
#
# passwd command (explicit because of a different authentication
module)
#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_projects.so.1
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account
management
#
other account requisite pam_roles.so.1
other account required pam_projects.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password
management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication (uncomment to use
Kerberos)
#
#rlogin auth optional pam_krb5.so.1
try_first_pass
#login auth optional pam_krb5.so.1 try_first_pass
#other auth optional pam_krb5.so.1 try_first_pass
#cron account optional pam_krb5.so.1
#other account optional pam_krb5.so.1
#other session optional pam_krb5.so.1
#other password optional pam_krb5.so.1 try_first_pass

Файл /etc/pam.conf состоит из правил – по одному правилу в строке. Если нужно, чтобы правило продолжалось на следующей строке, следует в конце продолжающейся строки поставить символ "\" для экранирования следующего за ним перевода строки.

Комментарии начинаются знаком "#" и продолжаются до конца строки (обратите внимание на то, что в вышеприведенном файле, поставляющемся по умолчанию, конфигурация Kerberos закомментирована).

Каждое правило состоят из пяти полей, которые отделяются друг от друга пробелами; первые три поля нечуствительны к регистру букв:

приложение задача управление путь/к/модулю аргументы_вызова_модуля

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

Несколько правил могут быть организованы в стек для последовательной аутентификации несколькими PAM-модулями. Поле "задача" характеризует ту задачу, которая решается модулем. Это может быть account; auth; password или session.

"Управление" определяет поведение PAM в случае, если модуль примет решение об отказе в аутентификации (допустим, сочтет пароль неверным). Возможные варианты действийТермин "отказ" мы употребляем в описании действий PAM в смысле "отказ в результате ошибки пользователя при аутентификации", например, указания неверного пароля.:

Путь к модулю – полное имя файла PAM-модуля для вызова приложением.

Аргументы модуля – разделенные пробелами аргументы, которые могут использоваться для изменения поведения модуля. Могут быть у любого модуля и определяются в документации на конкретный модуль.

Некоторые модули ограничиваются только поддержкой задачи auth.

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