27 Aug
2012
27 Aug
'12
10:35 p.m.
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?
thanks,
David
--
David Severance
Enterprise Unix Services
Office of Information Technology
(949) 824-7552
sev(a)uci.edu
24 Jan
24 Jan
12:53 a.m.
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.
4:28 a.m.
On 1/23/2013 4:53 PM, Simon Horman wrote:
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.
Actually I determined what was behind this issue but haven't been quick
to post what happened. Perdition is compiled will all the correct
options and this was the same binary that was previously being used when
we were successfully using pam_access to limit some users. What changed
was we turned off "authenticate_in" in perdition because we ran into
problems with capacity on our Kerberos service. That was awhile back,
then more recently I noticed that users listed in the
/etc/security/access.conf that pam_access read were not being processed.
I had thought if the pam access rules were listed in the Account section
that they would still be processed since they, the pam rules, were not
in the Auth section. However I'm not overly versed in pam so this may be
a conjuring of my mind as opposed to something that is indeed a real
problem. I just don't know enough about pam to know for sure what the
proper behavior should be.
David
--
David Severance
Enterprise Unix Services
Office of Information Technology
(949) 824-7552
sev(a)uci.edu
5:53 a.m.
On Wed, Jan 23, 2013 at 08:28:17PM -0800, David Severance wrote:
On 1/23/2013 4:53 PM, Simon Horman wrote:
The behaviour you describe above is most likely correct.
But unfortunately perdition isn't quite that clever.
If its still a problem for you I can look into fixing it.
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.
Actually I determined what was behind this issue but haven't been quick
to post what happened. Perdition is compiled will all the correct
options and this was the same binary that was previously being used when
we were successfully using pam_access to limit some users. What changed
was we turned off "authenticate_in" in perdition because we ran into
problems with capacity on our Kerberos service. That was awhile back,
then more recently I noticed that users listed in the
/etc/security/access.conf that pam_access read were not being processed.
I had thought if the pam access rules were listed in the Account section
that they would still be processed since they, the pam rules, were not
in the Auth section. However I'm not overly versed in pam so this may be
a conjuring of my mind as opposed to something that is indeed a real
problem. I just don't know enough about pam to know for sure what the
proper behavior should be.
4111
days inactive
4261
days old
3 comments
2 participants
participants (2)
-
David Severance -
Simon Horman