If you have an application that uses the PAM application API, it will use the PAM modules configured in /etc/pam.conf; if you have an application that uses the LAM application API, it will use the LAM modules configured in /usr/lib/security/methods.cfg.
The LAM module API for AIX 5.2 is documented here:
http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/kernextc/sec_load_mod.htmThe LAM module API was not documented in AIX 4.3, but my guess is that it was probably the same.
The patch includes a PAM module called pam_aix that "converts" PAM calls into the corresponding LAM calls, so that PAM-aware applications can make use of LAM even though they don't have any knowledge of the LAM application API. Because LAM provides AIX's default authentication mechanism, pam_aix can be used as the default module in /etc/pam.conf, much as pam_unix is on other platforms. For example:
other auth required /usr/local/lib/security/pam_aix.so other account required /usr/local/lib/security/pam_aix.so other session required /usr/local/lib/security/pam_aix.so other password required /usr/local/lib/security/pam_aix.so
To address this problem, IBM has backported their implementation of the pam_aix module from AIX 5.2 and made it available for AIX 5.1:
https://techsupport.services.ibm.com/server/nav/pamNote that IBM's implementation of pam_aix was done completely independently of the one I wrote for AIX 4.3. It does not support the same options, but it works the same otherwise.
Similarly to the way that pam_aix "converts" from PAM to LAM, AIX 5.2 also includes a LAM module that "converts" from LAM to PAM. The IBM documentation refers to this as the "PAM module", which is extremely confusing; to avoid this, I will refer to this module using its full path, /usr/lib/security/PAM.
As mentioned above, pam_aix is a PAM module that you configure in /etc/pam.conf, and it allows PAM-aware applications to make use of LAM even though they don't have any knowledge of the LAM application API. Conversely, /usr/lib/security/PAM is a LAM module that you configure in /usr/lib/security/methods.cfg, and it allows LAM-aware applications to make use of PAM even though they don't have any knowledge of the PAM application API.
The /usr/lib/security/PAM LAM module is documented here:
http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/security/pam_overview.htmUnfortunately, /usr/lib/security/PAM is not a very elegent solution, because it requires major modifications on the part of any PAM module that you want to use with it. Because the LAM API does not support the notion of a conversation function, all PAM modules must be modified to use the pam_get_item() and pam_set_item() calls to communicate with the application.
(If you're familiar with the PAM and LAM APIs, it's pretty obvious why this is a problem. PAM uses an out-of-band mechanism (the conversation function) to communicate with the application, while the LAM API uses iterative calls to the authenticate() function. Even if /usr/lib/security/PAM supplied its own conversation function for communicating with PAM, there's no reasonable way for the conversation function to jump back into the initial stack frame of the original authenticate() call without losing state between each iteration.)
Unfortunately, because the native AIX binaries (e.g., /bin/login and /bin/su) still call LAM directly, there is no reasonable way for them to use existing off-the-shelf PAM modules. The only alternative is to try to replace the native AIX binaries with open source alternatives that are PAM-aware, but that's a fairly complicated proposition, and I don't know of anyone who's actually tried to do that.
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/security/pam_overview.htmBack