Your message dated Tue, 28 Feb 2023 15:13:40 +0000
with message-id <[email protected]>
and subject line Bug#1032123: Removed package(s) from unstable
has caused the Debian Bug report #470509,
regarding libpam-ldap: Account-specific authentication failures when using 
SSL/STARTTLS
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
470509: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470509
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libpam-ldap
Version: 180-1.7
Severity: important


We have a vanilla OpenLDAP service setup on Debian Etch. We're not using
Kerberos, SASL, etc. We're attempting to migrate from an older
2.2.23-8.1 system to a new system using Etch's 2.3.30-5 and have run
into a bizarre problem:

1) Some users can authenticate correctly all of the time
2) All LDAP-based tools (e.g. ldapsearch, LDAP Browser) can authenticate
correctly all of the time
3) libpam-ldap will authenticate all users correctly if SSL/STARTTLS is
disabled in /etc/pam_ldap.conf
4) Some users will fail to authenticate if SSL or STARTTLS is enabled.
Non-authenticated services still work (e.g. getent passwd username)

Oddly, the error is reported as "Can't contact LDAP server" but the
client debug output suggests otherwise.

Fail:
2008-03-11T10:30:58+07:00       malacarne       authpriv        err     su      
su[17545]: pam_ldap: ldap_search_s Can't contact LDAP server 
2008-03-11T10:30:58+07:00       malacarne       authpriv        err     su      
su[17545]: pam_ldap: ldap_search_s Can't contact LDAP server
2008-03-11T10:31:01+07:00       malacarne       authpriv        err     su      
su[17545]: pam_ldap: ldap_simple_bind Can't contact LDAP server 
2008-03-11T10:31:01+07:00       malacarne       authpriv        err     su      
su[17545]: pam_ldap: ldap_simple_bind Can't contact LDAP server
2008-03-11T10:31:03+07:00       malacarne       authpriv        err     su      
su[17545]: pam_authenticate: Authentication service cannot retrieve 
authentication info. 
2008-03-11T10:31:03+07:00       malacarne       authpriv        err     su      
su[17545]: pam_authenticate: Authentication service cannot retrieve 
authentication
info.
2008-03-11T10:31:03+07:00       malacarne       authpriv        notice  su      
su[17545]: FAILED su for jb by cadams 
2008-03-11T10:31:03+07:00       malacarne       authpriv        notice  su      
su[17545]: FAILED su for jb by cadams
2008-03-11T10:31:03+07:00       malacarne       authpriv        info    su      
su[17545]: - pts/1 cadams:jb 
2008-03-11T10:31:03+07:00       malacarne       authpriv        info    su      
su[17545]: - pts/1 cadams:jb

Success:
2008-03-11T10:31:17+07:00       malacarne       authpriv        info    su      
su[17553]: Successful su for jb by cadams 
2008-03-11T10:31:17+07:00       malacarne       authpriv        info    su      
su[17553]: + pts/1 cadams:jb 
2008-03-11T10:31:17+07:00       malacarne       authpriv        info    su      
su[17553]: Successful su for jb by cadams
2008-03-11T10:31:17+07:00       malacarne       authpriv        info    su      
su[17553]: + pts/1 cadams:jb

I've attached debug traces of an su session with "ssl on" (fail.log) and
"ssl off" (success.log). tls_checkpeer yes/no makes no difference.

I've attached a much larger "big-debug.log" which is the result of
running with "debug 65535" in /etc/pam_ldap.conf. Starting at around
line 1336 you can see that it has queried a great deal of info about our
test account, which should not have been possible if it couldn't connect
to the server.

It's entirely possible that this is due to some stupid config on our end
and I would appreciate any debugging pointers as the logging is pretty
weak on operational diagnostics.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libpam-ldap depends on:
ii  debconf [debconf-2.0]  1.5.11etch1       Debian configuration management sy
ii  libc6                  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  libldap2               2.1.30-13.3       OpenLDAP libraries
ii  libpam0g               0.79-5            Pluggable Authentication Modules l

libpam-ldap recommends no packages.

-- debconf-show failed

Attachment: big-debug.log.bz2
Description: BZip2 compressed data

Attachment: fail.log.bz2
Description: BZip2 compressed data

Attachment: success.log.bz2
Description: BZip2 compressed data


--- End Message ---
--- Begin Message ---
Version: 186-4.1+rm

Dear submitter,

as the package libpam-ldap has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1032123

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

--- End Message ---

Reply via email to