Your message dated Thu, 25 May 2006 11:25:00 +1000
with message-id <[EMAIL PROTECTED]>
and subject line ignores LDAP account expiration details
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libpam-ldap
Version: 180-1
Severity: critical
Tags: security
If I set the Shadow account expiration date in Shadow using LAM to
1-1-2003, I can still log in using libpam-ldap.
I am sure I tested this functionality out before and it worked, as such
I feel this bug is critical because it may "introduce a security hole on
systems where you install the package". I think it is not-unreasonable
to expect it should not be possible to log in to an account that has
passed its expiration date.
It is also possible this is a bug in LDAP-Account-Manager (LAM), just
for verification my LDAP value is:
shadowExpire: 12052
I am not sure what the format of this number should be. In LAM it is
shown as corresponds to 31-12-2002.
--- End Message ---
--- Begin Message ---
On Thu, 2006-05-25 at 10:36 +1000, Brian May wrote:
> I am sure I tested this functionality out before and it worked, as such
> I feel this bug is critical because it may "introduce a security hole on
> systems where you install the package". I think it is not-unreasonable
> to expect it should not be possible to log in to an account that has
> passed its expiration date.
It looks like this might be a bug, but probably not a bug in libpam_ldap
or lam.
After reading /usr/share/doc/libpam-ldap/README.Debian I suspect NSS was
providing account information which was overriding my PAM configuration,
this was probably due to two reasons:
1. I used "shadow: files ldap" in /etc/nsswitch.conf, now fixed.
2. My chroot was not using shadow passwords - I am sure I already fixed
this, so either I am getting forgetful or something else weird happened
to disable shadow passwords again.
Anyway, closing this bug...
--- End Message ---
