PAM/ru

PAM или Pluggable Authentication Modules (подключаемые модули аутентификации) — это модульный подход к системе аутентификации. Они позволяют сторонним службам предоставлять модуль аутентификации для обеспечения доступа к службе для систем с поддержкой PAM. Службы, использующие PAM для аутентификации, могут использовать их сразу же, без необходимости дополнительной пересборки.

Введение
На сервере Linux PAM (Pluggable Authentication Modules) могут использоваться для управления аутентификацией (как часть управления предоставления доступа). При использовании PAM службам нет необходимости поддерживать собственную систему аутентификации. Вместо этого они полагаются на модули PAM, доступные в системе. Каждая служба при необходимости может использовать собственную конфигурацию PAM, хотя в большинстве случаев аутентификация выполняется одинаково для множества служб. Вызывая модули PAM, сервисы могут поддерживать двухфакторную аутентификацию «из коробки», сразу же использовать централизованные хранилища аутентификационных средств и многое другое.

PAM предоставляют гибкую модульную архитектуру для следующих служб:


 * Управление аутентификацией, проверяющее, является ли пользователь тем, за кого себя выдает.
 * Управление учётными записями, проверяющее, что пароль пользователя не истёк или имеет ли пользователь право обращаться к определённому сервису.
 * Управление сеансами, выполняющее определённые задачи во время входа или выхода пользователя из системы (аудит, мониторинг файловой системы и так далее).
 * Управление паролями, предлагающее интерфейс для сброса пароля и тому подобное.

Принципы работы PAM
При работе с PAM администраторы понимают принципы, по которым функционирует PAM.

Во-первых, это «независимость от бэк-энда». Приложениям, поддерживающим PAM, нет необходимости учитывать низкоуровневую логику, чтобы работать с бэк-эндами, например, базами данных, службой LDAP, файлами паролей, веб-службами с поддержкой WS-Security или другими ещё неизобретёнными бэк-эндами. Используя PAM, приложения отделяют логику работы бэк-энда от своей. Всё, что им нужно сделать — это вызвать функцию PAM.

Another principle is configuration independence. Administrators do not need to learn how to configure dozens of different applications on how to interact with an LDAP server for authentication. Instead, they use the same configuration structure provided by PAM.

The final principle, which is part of the PAM name, is its pluggable architecture. When new back-ends need to be integrated, all the administrator has to do is to install the library for this back-end (by placing it in the right directory on the system) and configure this module (most of the modules use a single configuration file). From that point onward, the module is usable for applications. Administrators can configure the authentication to use this back-end and usually just need to restart the application.

How PAM works
Applications that want to use PAM link with the PAM library (libpam) and call the necessary functions that reflect the above services. Other than that, the application does not need to implement any specific features for these services, as it is all handled by PAM. So when a user wants to authenticate itself against, say, a web application, then this web application calls PAM (passing on the user id and perhaps password or challenge) and checks the PAM return to see if the user is authenticated and allowed access to the application. It is PAMs task underlyingly to see where to authenticate against (such as a central database or LDAP server).

The strength of PAM is that everyone can build PAM modules to integrate with any PAM-enabled service or application. If a company releases a new service for authentication, all it needs to do is provide a PAM module that interacts with its service, and then all software that uses PAM can work with this service immediately: no need to rebuild or enhance those software titles.

Configuration
Another important aspect of PAM is that it supports chaining of multiple modules. Let's look at a PAM configuration file for an unnamed service:

We see that the configuration file is structured in the four service domains that PAM supports: authentication, account management, password management and session management.

Each of the sections in the configuration file calls one or more PAM modules. For instance, sets the environment variable which can be used by subsequent modules. The return code provided by the PAM module, together with the control directive (required or optional in the above example), allow PAM to decide how to proceed.

Control directives
PAM supports the following control directives.

Chaining of modules allows for multiple authentications to be done, multiple tasks to be performed upon creating a session and more.

Managing PAM configuration files
As the PAM configuration files control the authentication steps in an application, it is very important to safely manage the configuration files. These are generally stored in.

In larger enterprises, or security-sensitive systems, any modification of PAM configuration files should be properly audited.

The same goes for the location where the PAM modules themselves are stored ( or ).

PAM и Gentoo
Applications that can support PAM conditionally will use the 'pam' USE flag. Although it is possible to run Gentoo systems without PAM the default is to run with PAM support enabled.

Смотрите также

 * PAM (Security Handbook)
 * The Project:PAM Gentoo project
 * PAM ssh agent module article explaining how to install and configure a custom PAM module that authenticates through the SSH public key infrastructure
 * The Google authenticator article explains how to install and use the google authenticator application for authenticating through PAM

Ссылки

 * Working with PAM, a section inside the Gentoo developer manual