Re: trouble with pam
Simon Horman <[email protected]> Thu, 24 Jan 2013 09:53:30 +0900
| Newsgroups | gmane.mail.perdition.user |
|---|---|
| Message-ID | <[email protected]> |
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. ______________________________________________ Perdition-users mailing list [email protected] http://lists.vergenet.net/listinfo/perdition-users