[exim] LDAP Lookup, authenticators and failure

Top Page
Delete this message
Reply to this message
Author: Matthew Newton
Date:  
To: exim-users
Subject: [exim] LDAP Lookup, authenticators and failure
Hi All,

I'm setting up mail submission with authentication using LDAP
(actually an Active Directory server). I need to do a full LDAP
auth check (bind, search, bind, search) to check group memberships
- certain "public" users are in a particular group and should not
be allowed to log in.

The problem is that I often get the error "435 Unable to
authenticate at present" rather than "535 Incorrect authentication
data". When this system goes live that is likely to cause support
problems assuming the user gets to see the message.

The configuration I am currently using looks something like
(sorry, slightly obfuscated due to login + server details etc):

  server_condition     = ${lookup ldap \
                           { user=${quote:${lookup ldap \
                                    { user=SYSTEM_DN \
                                      pass=SYSTEM_PASS \
                                      referrals=nofollow \
                                      ldaps://LDAP_SERVER/\
                                      dc=le,dc=ac,dc=uk?\
                                      distinguishedName?sub?\
                                      sAMAccountName=${quote_ldap_dn:$auth1}\
                                    }\
                                  {$value}fail}} \
                             pass=${quote:$auth2} \
                             referrals=nofollow \
                             ldaps://LDAP_SERVER/\
                             dc=le,dc=ac,dc=uk?\
                             sAMAccountName?sub?\
                             (&(sAMAccountName=${quote_ldap_dn:$auth1})\
                               (!(memberOf=RESTRICTED_DN)))\
                           }\
                         {1}fail}


The "internal" lookup uses the system account+password to do a
search to find the DN of the user trying to log in. The "external"
lookup then binds as that user (to make sure the password is
correct) and then searches to make sure they are not in the
restricted users group. (Only the user themselves can use memberOf
to find their group membership.)

With an incorrect username and password, the "internal" lookup
(searching for username) fails, which causes the whole expansion
to fail and you get a "535 Incorrect authentication data".

With a correct username, but an incorrect password, you get the
following error:

28149 failed to bind the LDAP connection to server <LDAP_SERVER> - LDAP error 49: Invalid credentials
28149 lookup deferred: failed to bind the LDAP connection to server <LDAP_SERVER> - LDAP error 49: Invalid credentials

...which of course makes sense; the password is wrong. However,
that doesn't expand to "string2" (${lookup defn. in [1]), but
completely kills the expansion and defers.

I'd use ldapauth as the password check, but the documentation for
ldapauth[1] says: "The query itself is not used, and can be
empty." So I then can't check the group membership.

The only thing I can think of now is to do a "lookup ldap bind as
system" inside an "if ldapauth", inside a "lookup ldap bind as
user", which would be even more hideous than now...

So - questions:

Is there any way of always returning a "Incorrect authentication
data" error, rather than "Unable to authenticate"?

Maybe there is an easier way of doing the above that gets around
the error problem anyway?

And the main question:

If the lookup fails due to bad credentials, why does it not
expand to "string2"? This seems contrary to the documentation.
Maybe there should be a "string3" for "really bad failures to
lookup"??! ;-)

Any ideas?

Thanks in advance, and sorry for the long mail,

Matthew


[1] http://www.exim.org/exim-html-current/doc/html/spec_html/ch11.html

--
Matthew Newton <mcn4@???>

Network Support and UNIX Systems Administrator, Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <cchelp@???>