ivan mitev wrote:
sorry for the duplicate, gmail just showed the mail ; strange :(

Keep this on the list please...
before reporting the issue, i've done a diff with versions 0.58 and 0.59 of authldaprc and they're the same, so it doesn't seem like something has changed in the authentication design.
Well something has changed (from http://www.courier-mta.org/authlib/changelog.html):
0.59
<snip>

2006-10-28  Mr. Sam  <[EMAIL PROTECTED]>

        * Ported code to gcc 4.1.1

        * Ported authldap to openldap 2.3.27

<snip>
2006-06-01  [EMAIL PROTECTED]

        * authldaplib.c (auth_ldap_enumerate): Fix LDAP account enumeration

<snip>
2006-01-30  Mr. Sam  <[EMAIL PROTECTED]>

        * authldaplib.c: Try to recover when the LDAP server closes the
        persistent socket, for inactivity.

<snip>
0.58

from authldaprc:

##NAME: LDAP_BINDDN:0
#
# You may or may not need to specify the following.  Because you've got
# a password here, authldaprc should not be world-readable!!!
#LDAP_BINDDN            cn=administrator, o=example, c=com
#LDAP_BINDPW            toto

My authldaprc looks similar, works fine in 0.58 and not in 0.59. I should also mention that I'm on RHEL4u4 and:

# rpm -q openldap
openldap-2.2.13-6.4E.x86_64
##NAME: LDAP_AUTHBIND:0
#
# Define this to have the ldap server authenticate passwords. If LDAP_AUTHBIND # the password is validated by rebinding with the supplied userid and password. # If rebind succeeds, this is considered to be an authenticated request. This
# does not support CRAM-MD5 authentication, which requires clearPassword.
# Additionally, if LDAP_AUTHBIND is 1 then password changes are done under
# the credentials of the user themselves, not LDAP_BINDDN/BINDPW
#
LDAP_AUTHBIND           1

same here...
i don't know if authdaemon first binds anonymously to check if the user really exists and then tries to bind with the user credentials, or if it directly tries to binds with the user's creds - a ldap debug will show it ; but in both cases a global binddn/pw is not be needed.
With 0.58 authdaemon would have to first bind anonymously in order to lookup the context of the user (since the user may be in a subtree and for ldap login the full DN must be specified. Once it's anonymously looked up the user's DN, it tries to rebind with the DN as found and the password as provided.


begin:vcard
fn:Jay Lee
n:Lee;Jay
org:Philadelphia Biblical University;Information Technology Department
adr:;;;Langhorne;PA;19047;USA
email;internet:[EMAIL PROTECTED]
title:Network / Systems Administrator
x-mozilla-html:TRUE
url:http://www.pbu.edu
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to