Managing users and controlling their access is a challenging task in the current environment. AIX provides loadable authentication modules (LAM) for handling user identification and authentication (I & A). Users can write their own LAM modules by using the AIX loadable authentication modules framework (LAMF) interface. Similarly, AIX provides PAM for authentication. Users can integrate the PAM services to their native applications. This article provides an overview of PAM in AIX, usage of PAM library APIs, PAM service modules shipped in AIX, and the differences between LAM and PAM.
PAM framework provides support to integrate multiple authentication mechanisms to existing authentication mechanism. Prior to AIX V5.3 release, PAM module is provided as LAM module for handling native applications.
Figure 1 below provides an overview of PAM in AIX.
Figure 1. Figure 1. Illustration of PAM overview
Overview of PAM
The PAM framework is composed of 3 parts:
- PAM library: PAM interface library, /usr/lib/libpam.a, contains the PAM APIs. These APIs serves as a common interface to all PAM applications.
- PAM Configuration file: The /etc/pam.conf file contains service entries for each module type. Applications are registered with the PAM service module under this. This file is used by PAM library to interact with PAM service module.
- PAM modules: PAM service modules are available under the /usr/lib/security directory. These modules allow multiple authentication mechanisms to be used together or independently on a system.
PAM in AIX
Starting with AIX V5.1 Ml01, the PAM library /usr/lib/libpam.a is included as a part of the AIX release. Also, a standard set of PAM APIs is included under the PAM library; however, existing authentication application could not make use of the PAM.
In AIX V5.2, PAM is fully supported. The PAM module is provided as a LAM module at /usr/lib/security/PAM. Along with that pam_aix service module, the /etc/pam.conf file is also provided. Applications can use the PAM LAM module for authentication. The PAM module needs to be defined in the /usr/lib/security/methods.cfg file along with LAM module for authentication and identification.
Starting with AIX V5.3 and above, PAM is fully integrated into all AIX native applications and commands. The PAM LAM module is no longer required. A default /etc/pam.conf file is shipped along with additional PAM service modules. PAM can also be enabled for the entire system by changing the auth_type attribute to PAM_AUTH in the /etc/security/login.cfg file.
Table 1. Difference between PAM and LAM
|Performs authentication and identification.||Performs authentication only.|
|Entire system uses single authentication service.||An application on a system can be configured with multiple authentication services.|
|LAM modules need to be defined in /usr/lib/security/methods.cfg file.||PAM uses /etc/pam.conf file for defining application services.|
|LAM APIs are defined under AIX security library.||PAM APIs are defined under /usr/lib/libpam.a library.|
The PAM library provides a set of application program interfaces(APIs). These APIs enable applications to invoke the PAM modules and pass the information to a PAM module.
The following table provides description of some required APIs:
|pam_start||Establishes a new PAM session for user authentication. Initial PAM information has to be set with this call.|
|pam_authenticate||Authenticates user information through defined PAM module in /etc/pam.conf file.|
|pam_acct_mgmt||Performs various checks to validate user's account. This routine checks user account and password expiration details. This routine should be used based on return type of pam_authenticate.|
|pam_setcred||Changes or removes user's credentials for authentication. This routine is mainly used to change the current PAM session credentials, for example, if a user wants to switch from one account to another account (like su or swrole commands).|
|pam_open_session||Creates a new session for authenticated PAM user.|
|pam_end_session||Closes currently opened PAM user session.|
|pam_end||Ends an existing PAM authentication session.|
The /usr/lib/libpam.a library provides few other APIs. Refer resource section for more information about PAM library APIs.
See the Download section for a sample program using the above APIs.
Elements of /etc/pam.conf file
The /etc/pam.conf file is configured with application service entries for each PAM module type. Application service has to be defined under a valid module type with specific control flags.
Format of /etc/pam.conf file are:
<service_name> <module_type><control_flag><module_path>[module_options] #Authentication Management login auth required pam_aix telnet auth required pam_aix #Account Management login account required pam_aix telnet account required pam_aix #Password Management login password required pam_aix telnet password required pam_aix #Session Management login session required pam_aix telnet session required pam_aix
The service_name represents the application name which requires PAM service. If an application name is not specified in /etc/pam.conf file, it uses OTHER keyword to follow PAM module.
The Module_type specifies the module type for service. Valid module types are
- Authentication Management - auth
- Account Management - account
- Password Management - password
- Session Management - session
|auth||Authenticate users and set, refresh, or destroy credentials.|
|account||Determine validity of the user account and subsequent access after identification from authentication module.|
|password||Perform password modification and related attribute management.|
|session||Initiate and terminate user sessions.|
The Control_flag specifies the stacking behavior for module. Valid flags are required, requisite, sufficient, and optional.
|required||All required modules in a stack must pass for a successful result. If one or more fail, all of the required modules are attempted, but the error from the first failed required module is returned.|
|requisite||Similar to required except that if a requisite module fails, it immediately returns the first failure code from a required or requisite module.|
|sufficient||If a module flagged as sufficient succeeds and no previous required or sufficient modules have failed, all remaining modules in the stack are ignored and success is returned.|
|optional||Result ignored unless there are no required modules and no sufficient modules have succeeded.|
The Module_path specifies the PAM service module path on the system. The path may be either absolute path or just the module name. If absolute path is not specified, it assumes that /usr/lib/security for 32-bit applications and /usr/lib/security/64 for 64-bit applications.
The Module_options specifies a list of options supported by PAM service module. Some common options are:
|debug||Log debugging information to syslog.|
|nowarn||Do not display error messages.|
|try_first_pass||Try a previously entered password. If it fails, prompt for a new one.|
|use_first_pass||Use a previously entered password, do not prompt for a new one.|
The PAM service modules are a set of dynamically loadable objects invoked by the PAM-SPI (PAM-service provider interface) to provide a particular type of user authentication. AIX currently provides some PAM service modules, these provides at least one of module type described as above.
Quick reference table for all provided PAM service modules are:
|pam_aix||Perform AIX style authentication.|
|pam_allow||Returns PAM_SUCCESS for all invocations.|
|pam_allowroot||Returns PAM_SUCCESS if invoking user is root (uid = 0).|
|pam_ckfile||Provides checks similar to /etc/nologin.|
|pam_permission||Provides enhanced /etc/ftpusers type checking.|
|pam_prohibit||Returns a PAM failure code for all invocations.|
|pam_rhosts_auth||Performs rhosts authentication.|
The pam_aix module supports authentication, account, password and sessions management module types. This module can be configured in the /etc/pam.conf file to validate user's credentials on all databases. pam_aix module defines some of the SPI functions. These functions internally map with AIX security functions to handle user management tasks under different directories.
The pam_allow module simply returns PAM_SUCCESS for all invocations if the specified PAM handle is valid. For pam_sm_authenticate, the user must also be provided. This module should be used by system administrators with caution as it provides no real authentication. In most cases, this module should only be used for debugging purposes.
The pam_allowroot module requires invoking an application's real user ID; it should be 0 (zero). If the UID of the authenticating user is zero, then only pam_allowroot module returns PAM_SUCCESS. This module should typically be used as a sufficient module to allow root to bypass authentication or account management checks.
The pam_mkuserhome module creates the user's home directory automatically during a user's login if it doesn't already exist. This module should be used as optional in case of session module. It doesn't provide any other module types. It returns PAM_SUCCESS if the home directory already exists, or the home directory is successfully created on the system.
The pam_permission module checks for the existence of an optionally specified file and then reads the file to determine if a user/group is granted/denied access. Using this module, Authentication and Account Management module types are supported. This module supports following options:
Specify absolute path of the filename to allow user and groups. If no file is specified it reads /etc/ftpusers.
Entries in the file should follow the following format:
- + Grants access.
- - Denies access.
- @ Signifies the name is a group
The default value is prohibit, optional values are:
Value Entry match behavior allow, permit, pass Grant Access prohibit, deny, fail Deny Access
The debug option logs debugging information to the syslog file.
This option does not display warning information.
The pam_prohibit module returns a module specific failure for all services which are not specified in the /etc/pam.conf file. This module should be used by system administrators with caution as it provides no real authentication. In most cases, this module should be used to disable a module type or used in the OTHER service. The functionality works opposite to the pam_allow module. This supports all the PAM module types.
The pam_rhosts_module provides rhosts type of authentication facility similar to r-cmds like rlogin, rsh, and rexec. This module checks for username and hostname in /etc/hosts.equiv and followed by $HOME/.rhosts file. If a match is not found in the files, it returns PAM_AUTH_ERR failure code. It supports authentication PAM module type.
The pam_ckfile module allows or denies authentication based on existence of a file. This module provides functionality similar to the historic behavior of the /etc/nologin file. If the specified file exists, only the root user may authenticate. This module supports Authentication and Account Management module types. This module recognizes the file, debug, and nowarn options. The format of the options will be same as above.
AIX security commands and applications can be configured to call PAM modules through the use of existing loadable authentication framework. AIX supports PAM services from AIX V5.1 release. PAM is fully integrated into AIX from AIX V5.3 release. Users can use PAM library APIs in their applications for user/group authentication and account management. PAM also provides flexibility to integrate their existing authentication mechanism with PAM service module.
|Sample C program with PAM APIs||PAM-API.zip||10KB|
- AIX security documentation provides more information about PAM.
- Refer to the following PAM library documentation for more information about PAM APIs.
- In the XML area on developerWorks, get the resources you need to advance your XML skills, including DVDs, schemas, and XSLT.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Try out IBM software. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums: