какие средства могут быть использованы для аутентификации пользователей unix
Идентификация и аутентификация пользователей при работе подсистемы разграничения доступа в ОС Linux.
Презентация: скачать
Для этого необходимо создать PAM-модуль аутентификации, а логика работы процедуры и/а должна стать следующей:
— запускается утилита login
— утилита login делегирует функции и/а внешнему PAM-модулю, при этом:
— PAM-модуль запрашивает у пользователя login (или аппаратный идентификатор) и пароль;
— PAM-модуль рассчитывает хеш от предъявленных пользователем значений login (аппаратного идентификатора) и пароля и передает его модулю ядра по протоколу взаимодействия usermode-приложений с ядром ОС (протокол netlink);
— Модуль ядра ищет в своих структурах пользователя по login (аппаратному идентификатору) и сравнивает полученное от PAM значение хеша со значением в своей БД, при этом:
Дополнительно необходимо предусмотреть PAM-модуль для работы с сессиями пользователей с целью отделить механизм и/а и механизм управления сессиями, а также для возможности перехвата момента завершения сессии определенного пользователя (в модуле ядра этот факт должен также фиксироваться).
Также необходимо понимать, что наиболее важным элементов всей подсистемы разграничения доступа является наличие аппаратного компонента [1], с помощью которого на ранних этапах загрузки будет осуществляться:
Без таких контрольных процедур при использовании существующих штатных средств защиты в ОС всегда существует возможность обхода или отключения этих средств защиты на ранних этапах загрузки, что нивелирует любые механизмы защиты, реализуемые с помощью подсистемы разграничения доступа в ОС, т. к. появляется возможность данную подсистему просто отключить.
1. Бажитов И. А. Возможности ПАК СЗИ НСД «Аккорд-Х» для ОС Linux // Комплексная защита информации. Сборник материалов XIV Международной научно-практической конференции (19-22 мая 2009 года, Могилев). М., 2009. С. 26-27.
2. Бажитов И. А. Обеспечение доверенной среды в ОС Linux с использованием ПАК СЗИ НСД «Аккорд-X» // Комплексная защита информации. Сборник материалов XV Международной научно-практической конференции (1-4 июня 2010 года, Иркутск). М., 2010. С. 32.
Дата публикации: 01.01.2012
Библиографическая ссылка: Каннер А. М. Идентификация и аутентификация пользователей при работе подсистемы разграничения доступа в ОС Linux // Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15–18 мая 2012 года, Суздаль (Россия). М., 2012. С. 104–105.
Как использовать PAM-модули для локальной аутентификации в Linux по ключам ГОСТ-2012 на Рутокене
Простые пароли не защищают, а сложные невозможно запомнить. Поэтому они так часто оказываются на стикере под клавиатурой или на мониторе. Чтобы пароли оставались в головах “забывчивых” пользователей и надёжность защиты не терялась – есть двухфакторная аутентификация (2ФА).
Благодаря сочетанию факторов владения устройством и знания его PIN-кода, сам PIN-код может быть проще и легче для запоминания. Недостатки в длине или случайности PIN-кода компенсируются требованием физического владения и ограничениями на перебор PIN-кода.
Кроме того, в госучреждениях бывает, что хотят, чтобы всё работало по ГОСТу. О таком варианте 2ФА для входа в Линукс и пойдёт речь. Начну издалека.
PAM-модули
Подключаемые модули аутентификации (Pluggable Authentication Modules, PAM) — это модули со стандартным API и реализациями различных механизмов аутентификации в приложениях.
Все утилиты и приложения, умеющие работать с PAM, подхватывают их и могут использовать для аутентификации пользователя.
На практике это работает примерно так: команда login обращается к PAM, который выполняет все необходимые проверки с помощью указанных в конфигурационном файле модулей и возвращает результат обратно команде login.
librtpam
Разработанный компанией «Актив» модуль добавляет двухфакторную аутентификацию пользователей по смарт-картам или USB-токенам с помощью асимметричных ключей по последним стандартам отечественной криптографии.
Можно аутентифицироваться по ключам ГОСТ Р 34.10-2012 (длины 256 или 512 бит) или устаревшему ГОСТ Р 34.10-2001.
За безопасность ключей можно не беспокоиться – они генерируются непосредственно в Рутокене и никогда не покидают его память во время криптографических операций.
Практическое использование
1) Устанавливаем необходимые пакеты
2) Добавляем PAM-модуль с поддержкой ГОСТов
Загружаем библиотеку с https://download.rutoken.ru/Rutoken/PAM/
Копируем содержимое папки PAM librtpam.so.1.0.0 в системную папку
/usr/lib/ или /usr/lib/x86_64-linux-gnu/ или /usr/lib64
3) Устанавливаем пакет с librtpkcs11ecp.so
Загружаем и устанавливаем DEB- или RPM-пакет по ссылке: https://www.rutoken.ru/support/download/pkcs/
4) Проверяем, что Рутокен ЭЦП 2.0 работает в системе
5) Считываем сертификат
5.1) Создаём тестовый сертификат
Внимание! Описанные способы создания ключей и сертификатов подходят для тестирования и не предназначены для применения в боевом режиме. Для этого нужно использовать ключи и сертификаты, изданные доверенным центром сертификации вашей организации или аккредитованным удостоверяющим центром.
PAM-модуль создан защищать локальные компьютеры и подразумевает работу в небольших организациях. Поскольку пользователей немного, Администратор может сам следить за отзывом сертификатов и вручную блокировать учетные записи, как и за сроком действия сертификатов. PAM-модуль пока не умеет проверять сертификаты по CRL и строить цепочки доверия.
Простой путь (через браузер)
Для получения тестового сертификата используйте веб-сервис «Центр регистрации Рутокен». Процесс займёт не более 5 минут.
Путь гика (через консоль и, возможно, компилятор)
Генерируем ключевую пару с параметрами:
—key-type: GOSTR3410-2012-512:А (ГОСТ-2012 512 бит c парамсетом А), GOSTR3410-2012-256:A (ГОСТ-2012 256 бит с парамсетом A)
—id: идентификатор объекта (CKA_ID) в виде двузначных номеров символов в hex из таблицы ASCII. Используйте только ASCII-коды печатных символов, т.к. id нужно будет передать OpenSSL в виде строки. Например, ASCII-кодам “3132” соответствует строка «12». Для удобства, можно воспользоваться онлайн-сервисом конвертации строки в ASCII-коды.
Можно воспользоваться услугами тестового УЦ, коих много, например, вот, вот и вот, для этого создадим запрос на сертификат
6) Регистрируем сертификат в системе
Убедитесь, что ваш сертификат выглядит как base64 файл:
Если ваш сертификат выглядит так:
то нужно сконвертировать сертификат из формата DER в PEM-формат(base64)
Добавляем сертификат в список доверенных сертификатов
$ mkdir
/.eid/authorized_certificates
$ chmod 0644
/.eid/authorized_certificates
Последняя строка защищает список доверенных сертификатов от случайного или намеренного изменения другими пользователями. Это исключает ситуацию, когда кто-то добавит сюда свой сертификат и сможет входить в систему от вашего имени.
7) Настраиваем аутентификацию
сохраняем файл, после этого выполняем
$ sudo pam-auth-update
в появившемся окне ставим звёздочку около Rutoken PAM GOST и нажимаем OK
8) Проверяем настройку
Чтобы понять что всё настроено, но при этом не потерять возможность входа в систему введите команду
$ sudo login
Введите имя пользователя. Всё настроено правильно, если система потребует PIN-код устройства.
9) Настраиваем блокировку компьютера при извлечении токена
Описанные шаги по настройке операционной системы можно использовать как инструкцию в любом современном дистрибутиве Linux, включая отечественные.
Аутентификация пользователей UNIX средствами AD
Централизация аутентификации клиентов UNIX в смешанной среде
Пользователи гетерогенных сетей на базе Windows и UNIX часто имеют несколько учетных записей UNIX для доступа к системам UNIX и доменную учетную запись в Active Directory (AD) — для доступа к ресурсам Windows. Такая организация доступа давно уже вызывает нарекания со стороны администраторов и специалистов в области безопасности: дело в том, что, если пользователи имеют целый ряд учетных записей или применяют их не слишком часто, пароли забываются. В результате сотрудники, которым приходится запоминать большое количество паролей, часто записывают их на листках бумаги и оставляют эти записи на рабочем месте. Чтобы обеспечить защиту данных в таких сетях, некоторые администраторы используют имеющуюся в системе UNIX службу Network Information Service (NIS). Она позволяет создавать центральную базу данных пользовательских учетных записей для нескольких систем UNIX, так что для регистрации в различных системах UNIX пользователь может задействовать одну и ту же учетную запись. Однако с течением времени значение такого фактора, как безопасность, постоянно возрастает, и многие организации стремятся повысить уровень защиты своих информационных систем за счет проведения усиленной парольной политики на обеих платформах — и Windows и UNIX.
Сильная парольная политика в сетях с AD должна не только предусматривать определенный уровень сложности паролей и ограничения на повторное их использование, но и регулировать сроки действия паролей и обеспечивать их блокировку. Требования AD относительно уровня сложности паролей состоят в том, что в каждом пароле обязательно должны присутствовать символы трех из имеющихся четырех типов знаков: строчные буквы, прописные буквы, цифры и специальные символы, причем пароль должен состоять как минимум из шести знаков. В соответствии с заложенными в службе AD требованиями к истории паролей, пользователи могут вновь задействовать старый пароль лишь после смены определенного, указанного администратором числа паролей (скажем, после смены 10 паролей). К сожалению, ни одна из версий UNIX и Linux (это же, кстати, относится и к службе NIS) не имеет собственных средств для поддержки предусмотренного службой AD уровня сложности паролей и порядка возврата к старым паролям. Хотя в то же время они обеспечивают уровень сложности паролей на другом уровне: в каждом пароле должны присутствовать по меньшей мере две строчные или прописные буквы и не менее одной цифры или символа. Кроме того, они предъявляют ряд требований к составлению новых паролей взамен старых: в новом пароле должно быть хотя бы три знака, которых не было в старом пароле. Многие предлагаемые независимыми поставщиками средства аутентификации и управления учетными записями позволяют проводить усиленную парольную политику на нескольких платформах, но эти средства дорого стоят и их сложно реализовать. Продукт Microsoft Services for UNIX (SFU) позволяет устанавливать службы NIS на контроллерах доменов AD и применять объект «пользователь» службы AD для хранения свойств и учетных данных пользователя UNIX, но и в этом случае при регистрации в системах UNIX и в сетях с AD пользователю приходится иметь дело с разными паролями.
Подход, описываемый в настоящей статье, представляет собой самое простое, быстрое и экономичное решение проблемы централизованной аутентификации пользователей UNIX средствами AD. Предлагаемая схема дает пользователям UNIX возможность применять их доменные учетные записи AD для регистрации в системах UNIX (т. е. каждый пользователь должен помнить лишь один пароль) и обеспечивает реализацию в системах UNIX усиленной парольной политики AD.
 |
| PAM-архитектура системы аутентификации пользователей UNIX средствами AD |
Что такое PAM
Почти все современные версии UNIX и Linux используют разработанную Open Software Foundation (OSF) архитектуру Pluggable Authentication Module (PAM). Эта архитектура позволяет с легкостью интегрировать в системы UNIX различные технологии аутентификации, такие как UNIX, протоколы Lightweight directory Access Protocol (LDAP), Kerberos и смарт-карты для наделенных средствами PAM приложений и служб, например login, passwd, rlogin, telnet и ftp. PAM-совместимые службы и приложения не занимаются аутентификацией пользователей, эта задача возлагается на отдельные PAM-модули. По умолчанию для аутентификации в системах UNIX используются модули UNIX PAM; при этом применяются файлы passwd и shadow passwd, где хранится информация о пользовательских учетных записях и паролях. Но архитектура PAM позволяет с легкостью добавлять и использовать альтернативные модули PAM и перекладывать бремя аутентификации пользователей на другие системы, которые будут выполнять эту процедуру в соответствии с особенностями конкретного приложения и требованиями к защите данных. Так, модуль LDAP PAM позволяет осуществлять аутентификацию пользователей с помощью службы каталога LDAP, такой как AD, Novell eDirectory, OpenLDAP и разработанного корпорацией Sun Microsystems средства Sun ONE Directory Server. Модуль Kerberos PAM дает возможность выполнять процедуру аутентификации с помощью Kerberos Distribution Center (KDC), в частности Heimdal Kerberos, Massachusetts Institute of Technology (MIT) Kerberos, Sun Enterprise Authentication Mechanism (SEAM) и Windows 2000 Kerberos. Стоит отметить, что PAM позволяет осуществлять аутентификацию, но не авторизацию системных ресурсов, к которым пользователь получает доступ после регистрации в системе.
Сравнив модули LDAP PAM и Kerberos PAM, я обнаружил, что проще развертывается модуль LDAP PAM — как с точки зрения администраторов Windows, так и с позиции администраторов UNIX-систем. Давайте более подробно остановимся на реализации модуля LDAP PAM в службе AD. Те, кто желает познакомиться со средствами аутентификации пользователей средствами реализованной в Windows 2000 службы Kerberos for UNIX, могут обратиться к статье «Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability», опубликованной на сайте Microsoft.
Как функционирует программа LDAP PAM
LDAP PAM (pam_ldap) — это бесплатно распространяемая программа с открытым исходным кодом. PADL Software, компания, разработавшая библиотеку pam_ldap, поддерживает исходный код программы и расширяет ее функциональные возможности. Поставщики UNIX, как правило, оснащают свои версии операционной системы поставляемой PADL Software программой pam_ldap или библиотеками pam_ldap собственной разработки. Последние версии Linux тоже включают в себя программу pam_ldap.
LDAP PAM управляет аутентификацией пользователей UNIX в каталогах LDAP. При этом для взаимодействия с соответствующим каталогом LDAP используется клиент UNIX LDAP или программа от независимого поставщика, например OpenLDAP. Если имеющаяся версия UNIX наделена собственными средствами для взаимодействия с Secure Sockets Layer (SSL) или используются SSL-средства независимых поставщиков, скажем OpenSSL, и клиент LDAP, а также соответствующий каталог совместимы с SSL, модуль LDAP PAM может для обеспечения безопасного взаимодействия между системой UNIX и каталогом LDAP использовать протокол LDAP over SSL (LDAPS). AD автоматически получает возможность взаимодействовать с LDAPS в случае, если на контроллерах доменов AD установлены сертификаты серверов. Рассмотрим процесс аутентификации от LDAP PAM к AD, который проиллюстрирован представленной на рисунке архитектурой PAM.
Когда оснащенная средствами PAM служба или приложение выполняет процедуру аутентификации пользователя (например, в случае, если пользователь обращается по протоколу telnet к серверу UNIX), она обращается к библиотеке PAM. Последняя вызывает модуль аутентификации, который требуется службе или приложению в соответствии с конфигурацией PAM, указанной в файле pam.conf (процедура настройки PAM будет рассмотрена позже). Затем на основе спецификаций взаимодействия, определенных в файле ldap.conf, модуль LDAP PAM предоставляет необходимую для регистрации информацию службе AD. После этого служба LDAP каталога AD сопоставляет предоставленные регистрационные данные пользователя с учетными данными пользователя, хранящимися в AD, и применяет парольную политику AD для аутентификации пользователя.
Перед тем как пользователь сможет по завершении процесса аутентификации зарегистрироваться в системе UNIX, система должна создать среду, включающую идентификационный номер пользователя UNIX, основной каталог и применяемую по умолчанию оболочку. Эти атрибуты, не являющиеся частью пользовательских атрибутов в системе AD, генерируются в тот момент, когда создается учетная запись UNIX, и хранятся в локальном файле passwd на сервере NIS. Следовательно, необходимость хранения учетных записей UNIX на каждой системе UNIX остается; однако от пользователей уже не требуется знания их учетных данных для системы UNIX; они могут даже не знать о том, что имеют учетную запись на локальной системе. Иначе говоря, модуль PAM можно сконфигурировать таким образом, чтобы пользователи для регистрации в данной системе могли задейтвовать не учетные записи UNIX, а учетные записи AD.
Установка LDAP PAM
Библиотечный файл pam_ldap, который часто называется pam_ldap.so.1 или pam_ldap.so, в большинстве UNIX-систем располагается в каталоге /usr/lib/security, но часто случается, что данная версия старше, нежели файл pam_ldap, распространяемый компанией PADL. А более ранние версии часто не взаимодействуют со службой AD, поскольку их создатели не ставили перед собой задачу обеспечивать совместимость со службой AD. Поэтому, если предоставляемый поставщиком используемой версии UNIX файл pam_ldap не имеет совместимости с AD, я рекомендую или загрузить текущую версию файла pam_ldap с сайта фирмы PADL (http://www.padl. com/OSS/pam_ldap.html) и откомпилировать его своим силами, или получить бинарный пакет на Web-узле консалтинговой компании Symas (http://rebec.symas. net/download/connexitor).
В процессе установки файла pam_ldap на системе Sun Solaris 2.8 я обнаружил, что входящий в комплект поставки Solaris 2.8 файл pam_ldap несовместим с AD, но предоставляемый фирмой PADL файл pam_ldap 164 (новейшая версия) хорошо взаимодействует с этой службой. Так что, если планируется использовать pam_ldap в системе Solaris 2.8, можно следовать изложенным ниже инструкциям (тем, кто пользуется не Solaris, а другой системой, возможно, придется внести в эти инструкции некоторые изменения). Для компилирования и поддержки файла pam_ldap я пользуюсь бесплатно распространяемыми программными средствами с открытым исходным кодом. Итак:
1. Следует установить необходимые для генерирования исполняемых файлов компоненты GNU Compiler collection (Gcc), make, automake и autoconf. Эти инструменты понадобятся для создания файла pam_ldap и зависимых от него файлов. Новейшую, стабильно функционирующую версию Gcc 3.3 можно загрузить по адресу http://www.gnu.org/directory/gnu/gcc.html, версию make 3.80 — по адресу http://www.gnu.org/directory/gnu/make.html, версию automake 1.76 — по адресу http://www.gnu.org/directory/gnu/automake.html и версию autoconf 2.57 — по адресу http://www.gnu.org/directory/gnu/autoconf.html. Бинарные пакеты Gcc, make, automake и autoconf можно найти по адресу http://www.sunfreeware.com.
2. Необходимо загрузить и установить генератор случайных чисел, с помощью которого модуль SSL будет генерировать ключи шифрования. Хорошим генератором является программа Pseudo Random Number Generator Daemon (PRNGD) 0.9.27. Ее исходный код можно получить на узле http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html. Бинарный пакет версии 0.95 доступен по адресу http://www.sunfreeware.com.
3. Для обеспечения взаимодействия с SSL следует загрузить и установить новейшую версию OpenSSL 0.9. 7b.
Исходный код можно получить по адресу http://www.openssl.org. Имеется и бинарный пакет. Он доступен по адресу http://www.sunfreeware.com.
4. Требуется загрузить исходный код программы OpenLDAP 2.1.22, размещенный по адресу http://www.openldap.org/software/download. Перед тем как приступить к компилированию OpenLDAP, нужно установить параметры окружения с помощью следующих команд:
Далее с помощью перечисленных ниже команд из каталога исходного кода OpenLDAP следует выполнить компиляцию и установку клиента OpenLDAP и используемой программой pam_ldap функции LDAPS:
5. Необходимо применить следующие команды для компиляции и установки файла pam_ldap 164 из каталога pam_ldap:
Ключи в команде configure извещают программу pam_ldap о том, что необходимо использовать реализованные в OpenLDAP функции LDAP и конфигурацию LDAP и файла /etc/ldap.conf. Программа размещает файл pam_ldap.so.1 в каталоге /usr/lib/security.
Настройка модуля LDAP PAM
Чтобы иметь возможность задействовать программу pam_ldap, нужно предварительно настроить в системе UNIX файлы ldap.conf и pam.conf. Необходима также настройка службы AD в системе Windows 2000. Вместе с исходным кодом pam_ldap компания PADL предоставляет шаблонные коды файлов ldap.conf и pam.conf, но их надлежит модифицировать в соответствии с особенностями конкретной сети. Рассмотрим для начала, как осуществляется настройка файла ldap.conf, а затем перейдем к настройке AD и pam.conf.
В листинге 1 ((http://www.secadministrator.com, InstantDoc ID 39989) представлен шаблонный файл ldap.conf, который я использовал для настройки доступа к AD средствами pam_ldap. Код в метке A в листинге 1 указывает базу поиска отличительного имени LDAP (DN, т. е. строка с полным AD-именем организации) и предписывает LDAP выполнять поиск объектов и атрибутов в базе поиска, включая все организации-потомки, до тех пор пока LDAP не найдет (или пока не придет к выводу о том, что не в состоянии найти) искомый объект в пределах указанного пользователем отрезка времени — в данном случае 30 секунд.
Код в метке B показывает унифицированные идентификаторы ресурсов (Uniform Resource Identifiers, URI) сервера AD LDAP, которые будет использовать программа pam-ldap. Когда указывается несколько контроллеров доменов, как в приведенном примере, при недоступности текущего контроллера домена аутентификация может быть передана следующему доступному контроллеру. LDAPS осуществляет шифрование LDAP-сообщений с тем, чтобы учетные данные пользователя были защищены на этапе передачи их от системы UNIX в службу AD. Кроме того, код в метке B предлагает LDAPS использовать TCP-порт 636 и указывает версию сервера LDAP; дело в том, что служба AD совместима лишь с новейшей версией, а именно c LDAP 3.0.
Далее код предоставляет LDAP соответствующее имя DN и пароль для регистрации в службе AD в течение установленного времени (скажем, 30 секунд) и выполняет просмотр объекта и атрибутов пользователя LDAP для аутентификации пользователя UNIX. Предоставленная для регистрации связующая учетная запись LDAP может быть гостевой учетной записью из группы Domain Guests; записи такого рода не имеют особых привилегий доступа. Пользоваться предусмотренной в службе AD учетной записью anonymous нельзя, так как данная учетная запись не допускает возможности просмотра атрибута sAMAccountName объекта «пользователь», что необходимо в процессе аутентификации средствами pam_ldap. AD позволяет администратору определять группу и включать в нее только тех пользователей, которые имеют полномочия на регистрацию в системе UNIX. Код в метке C указывает, что pam_ldap позволяет регистрироваться в системе только тем пользователями, которые являются членами группы Unix-System1. Этот основанный на проверке принадлежности к группе критерий не допускает к регистрации в системе пользователей, не имеющих на то полномочий, в случаях, когда администратор забыл удалить старую учетную запись пользователя для системы UNIX или случайно создал в системе учетную запись этого пользователя. Последняя строка кода в листинге 1 указывает, что пароль пользователя является паролем для службы AD.
Можно создать собственный файл ldap.conf, если заменить шаблонные имена в коде соответствующими именами из своей системы. Затем следует сохранить этот файл на системе UNIX в каталоге /etc и защитить его, предоставив права на чтение или изменение этого файла только обладателю учетной записи root.
Настройка AD
Процедура настройки AD, обеспечивающая функционирование программы pam_ldap, проста и не вызывает никаких затруднений. Сначала нужно создать гостевую учетную запись, являющуюся связующей учетной записью LDAP (о том, как это сделать, я рассказывал выше), а затем наделить эту запись лишь теми привилегиями, которые предусмотрены для членов группы Domain guests с сильным паролем. Далее нужно создать для системы UNIX глобальную группу, такую как UNIX-System1, и ввести в эту группу всех пользователей, которым требуется доступ к данной системе. Чтобы служба AD могла взаимодействовать с LDAPS, следует установить — во всяком случае, на тех контроллерах доменов, которые задействует программа pam_ldap, — службу Windows 2000 Certificate Services или сервер сертификатов от независимого поставщика. Я, например, использовал сервер Certificate Services операционной системы Windows 2000 и с помощью глобальной общей политики обеспечил автоматическое получение сертификатов всеми контроллерами доменов.
Настройка PAM
Чтобы дать пользователям возможность регистрироваться в системах UNIX с помощью службы AD, нужно пройти еще один важнейший этап — этап настройки модулей PAM. Архитектура PAM обеспечивает выполнение четырех функций управления: auth (аутентификация), account (учетная запись), session (сеанс) и password (пароль). Функция auth устанавливает учетные данные пользователей и осуществляет их аутентификацию; функция account выполняет проверку учетных записей пользователей (скажем, проверяет правильность паролей и сроки прекращения действия учетных записей); функция session устанавливает и прекращает сеансы регистрации, а функция password управляет изменениями паролей. Настройку всех четырех указанных функций необходимо выполнять в файле pam.conf. Каждая запись в любой представленной в файле pam.conf функции управления содержит имя службы или приложения, за которым следует функция управления, ключ управления, путь к библиотеке аутентификации и дополнительный параметр. В листинге 2 (http://www.secadministrator.com, InstantDoc ID 39989) представлен образец файла pam.conf, на примере которого я покажу, как настраивается модуль PAM.
В качестве имени службы или приложения может использоваться имя любой оснащенной средствами PAM службы или приложения UNIX. В листинге 2 login в первом поле предназначен для регистрации на консоли системы; другие включают остальные PAM-совместимые службы и приложения, в том числе telnet, ftp, ssh, su и sudo. Если для работы с определенной службой или приложением желательно использовать конкретные модули аутентификации (например, sudo), можно создать для sudo одну или несколько отдельных записей. Второе поле задает функцию управления (это может быть auth, account, session или password), которая взаимодействует со службой или приложением.
Третье поле — это ключ, управляющий применением данной функции управления. К примеру, в коде, содержащемся в метке A листинга 2, контрольный ключ, достаточный для службы регистрации, означает, что аутентификация прошла успешно, аутентификация завершается; иначе PAM вызывает модуль PAM, на который указывает код в метке B. Поскольку требуется контрольный ключ в коде, представленном в метке B, пользователь может зарегистрироваться на консоли, только если аутентификация прошла успешно.
В четвертом поле записи указывается путь доступа к библиотеке модуля PAM. Путь доступа, обозначенный в коде метки A, указывает на библиотеку pam_ldap, а путь, приведенный в метке B, указывает на pam_unix (собственная программа аутентификации системы UNIX). Поэтому, когда пользователь регистрируется на системной консоли, система сначала выполняет процедуру аутентификации в AD, и, если эта процедура не завершается успешно, PAM проводит аутентификацию средствами UNIX. При выполнении приведенного в метке B варианта try_first_pass PAM не предлагает пользователю повторно ввести пароль для аутентификации средствами UNIX, а вместо этого автоматически применяет пароль, введенный пользователем для аутентификации средствами AD. Приведенный в метке C вариант ignore_unknown_user подразумевает, что, если в каталоге AD нет учетной записи данного пользователя, PAM ищет соответствующую учетную запись в системе UNIX. Этот шаблонный файл pam.conf позволяет пользователю, скажем администратору, имеющему возможность физического доступа к системе, регистрироваться с системной консоли. Когда данная система UNIX теряет связь с сетью, администратор, которому нужно найти причину неполадки, может зарегистрироваться на консоли, используя локальную учетную запись root. В сценарии также указывается, что все остальные службы (кроме login) и приложения при выполнении аутентификации пользователей и при проверке учетных записей должны задействовать только службу AD. Pam_ldap не имеет функции управления сеансами, поэтому для управления сеансами связи PAM должна прибегать к помощи модуля UNIX PAM, как указано в коде метки D (и это, кстати говоря, еще одно основание для того, чтобы хранить пользовательские учетные записи UNIX непосредственно в системе). Последние строки кода указывают, что если в каталоге AD нет учетной записи пользователя, то в случаях, когда системный администратор изменяет пароль данного пользователя, PAM изменяет его пароль в учетной записи UNIX.
Файл pam.conf следует редактировать и сохранять в каталоге /etc системы UNIX. Перезагружать систему после конфигурирования PAM не нужно. Система фиксирует изменения автоматически в ходе следующего сеанса аутентификации пользователя. Теперь она готова к аутентификации пользователей UNIX средствами AD.
Всего лишь первый шаг
Служба AD обеспечивает добротную централизованную инфраструктуру аутентификации в масштабе всего предприятия. Модуль LDAP PAM позволяет задействовать службу AD для создания централизованной системы аутентификации пользователей UNIX. Наряду с этим он дает возможность облегчить решение возложенной на администраторов задачи управления паролями, освободить пользователей от необходимости запоминать множество паролей и реализовать усиленную парольную политику на платформах Windows и UNIX. Впрочем, применение службы AD для аутентификации пользователей UNIX — всего лишь первый шаг на пути к созданию объединенной системы управления пользователями уровня предприятия. Учетные записи пользователей UNIX на системах UNIX нужно обслуживать даже в тех случаях, когда пользователям нет необходимости знать, что у них есть учетные записи UNIX. Можно задействовать службу AD для хранения и управления сведениями об учетных записях пользователей UNIX и избавиться от необходимости постоянно контролировать действия пользователей UNIX на отдельных системах. Об этой функции будет рассказано в одной из следующих статей.