The example you quote builds a distinguished name and tries to bind as
with the credentials given during the authentication, which is the only way
possible if your LDAP server doesn't hold passwords in clear text.
This works fine for me; it takes the userid and the password given during
the authentication phase, looks up the DN of the LDAP user (the inner lookup
ldapdn) because I cannot construct the DN, and then tries to bind as that
user to the directory, if that user has a mail account. The BASEDN
variable points to the top of my directory tree as in `BASEDN = dc=company,dc=com'
ldap_login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${\
lookup ldap { \
user="${lookup ldapdn {ldap:///BASEDN?dn?sub?(&(uid=${quote_ldap:$1})(mail=*))}}" \
pass="$2" \
ldap:///BASEDN?uid?sub?(&(uid=${quote_ldap:$1})(mail=*)) \
}{yes}fail \
}
server_set_id = $1
All this was built from scraps found on the net.
Regards,
-JP
On Tue, 24 Feb 2004, Torsten Schlabach wrote:
> I am trying to set up SMTP auth with LDAP; especially to support the LOGIN
> mechanism. (Guess for what MTA ...?)
>
> What confuses me in the first place is that some example (in the Exim spec,
> which is the only documentation that I stick to as a lot of the stuff out
> there on the net is still 3.x and therefore outdated) use the lookup ldap way
> while the specific example for the LOGIN authenticator
>
> (from Section 34.3)
>
> login:
> driver = plaintext
> public_name = LOGIN
> server_prompts = Username:: : Password::
> server_condition = ${if ldapauth \
> {user="cn=${quote_ldap_dn:$1},ou=people,o=example.org" \
> pass=${quote:$2} \
> ldap://ldap.example.org/}{yes}{no}}
> server_set_id = uid=$1,ou=people,o=example.org
>
> is using ldapauth.
>
> So what's happening to my understanding is that it is not trying to look up
> the user credentials on the LDAP server but it is trying to log in to LDAP
> using the credentials of the person who is trying to send mail with that MTA.
