On Mon, Aug 27, 2012 at 03:35:15PM -0700, David Severance wrote:
When we originally implemented perdition v1.17 on
RHEL4 several years
ago we had a customized the /etc/pam.d/perdition file to use the
pam_access.so module so we could lock out accounts for
administrative/maintenance purposes. This worked well for many years.
Within the last year we upgraded to RHEL5 and perdition 1.19rc4 and then
rc5. It would appear that since this update perdition no longer seems to
pay any sort of attention to the contents of the pam file and will
always assume success. Nothing seems to be logged either unlike before.
Although we are now compiling perdition to be located in /usr/perdition
with it's conf files in /etc/perdition I don't see how that would affect
pam operations, at least I would think it shouldn't. ldd on perdition
does show pam libraries being linked. Any ideas?
Perhaps perdition is being built without PAM support. This could occur for
one of several reasons:
* --disable-pam was passed as a command-line argument to ./configure
* Perdition was unable to find security/pam_appl.h at configure-time
* Perdition was unable to find the symbol pam_authenticate in libpam
at configure-time.
In all cases of the above cases something relating to pam being disabled
should show up in the output of ./configure.