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,
/* 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
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));
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
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
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
## 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/