On 9 August 2017 at 16:15, Jeremy Harris <j...@wizmail.org> wrote:

> It's explicitly how it's coded.

Agreed: I believe I've tracked down the relevant bit of code,
in src/lookups/ldap.c

  /* Invalid credentials when just checking credentials returns FAIL. This
  stops any further servers being tried. */

  if (search_type == SEARCH_LDAP_AUTH && rc == LDAP_INVALID_CREDENTIALS)
      debug_printf("Invalid credentials: ldapauth returns FAIL\n");
    error_yield = FAIL;

  /* Otherwise we have a problem that doesn't stop further servers from
  tried. */

  if (rc != LDAP_SUCCESS)
    *errmsg = string_sprintf("failed to bind the LDAP connection to server "
      "%s%s - LDAP error %d: %s", host, porttext, rc, ldap_err2string(rc));
    goto RETURN_ERROR;

If you're doing an auth-only to check credentials it only yields a FAIL if
the return code is LDAP_INVALID_CREDENTIALS (49). Any other return code
falls through to put the error string into errmsg and return without
indicating a FAIL. And from the logs I'm getting error code 32 back, which

The weird thing is that the help page for LDAP_INVALID_CREDENTIALS
<http://ldapwiki.com/wiki/LDAP_INVALID_CREDENTIALS> (49) at Ldapwiki says:

LDAP_INVALID_CREDENTIALS, which is LDAP Result Code 49, implies an
Authentication Failure. Typically, the Distinguished Name (DN) or the
password is *invalid*.

Whilst the help page for LDAP_NO_SUCH_OBJECT
<http://ldapwiki.com/wiki/LDAP_NO_SUCH_OBJECT> (32) at Ldapwiki says:

LDAP_NO_SUCH_OBJECT is *NOT* returned on following operations:

   - Search operations that find the search base but cannot find any
   entries that match the search filter.
   - Bind operations

Together these seem to suggest I should be getting LDAP_INVALID_CREDENTIALS
back from our LDAP server if the DN or password are invalid, and that
should never be returned for a bind operation. I might mention it to the
LDAP guys here, who are in another team, and try to engage their interest.

Possible workaround, then: check explicitly for a valid username
> before checking the password?

Unfortunately I don't believe I have a way of doing this, being unable to
search the LDAP repository without first binding/authenticating, and
credentials to do such searches are guarded by leopards.

(It is possible to code a test for a "defer" explicitly in ACLs, but
> it's a trifle complex.  If you prefer that route, ask and I'll look it
> up)

Many thanks for the offer but I think I'll quit worrying, leave the setup
as-is with a deferral response to the AUTH, and move on.

This all came about because I was starting to look at rate limiting failed
attempts to AUTH along these lines
(Although I have my suspicions as to whether it will work as the author of
that post says after a failed authentication attempt Exim will go straight
to the check_quit or check_not_quit ACLs, whereas I see it happily letting
the client try to authenticate again down the same connection. I'll keep

Mike B-)

Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to