On 9 August 2017 at 16:15, Jeremy Harris <jgh@???> 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(D_lookup)
debug_printf("Invalid credentials: ldapauth returns FAIL\n");
error_yield = FAIL;
goto RETURN_ERROR_NOMSG;
}
/* Otherwise we have a problem that doesn't stop further servers from
being
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
is LDAP_NO_SUCH_OBJECT.
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
<
https://lists.exim.org/lurker/message/20120709.015548.eb9d2ba2.en.html>.
(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
playing.)
Cheers,
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
