On Thu, Nov 23, 2023 at 11:06 PM Graham Leggett via dev <dev@httpd.apache.org> wrote: > > On 23 Nov 2023, at 13:28, Yann Ylavic <ylavic....@gmail.com> wrote: > > Unfortunately the message is correct and we do just that via > get_dn_for_nonldap_authn (line 1451). The DN you mention we look for > later in line 1480 via util_ldap_cache_getuserdn. > > > My guess was that if r->user is set we always want to use it for ldap > requests/authn? Or maybe there should be another Require ldap-!search > > configured to achieve that (if wanted) since ldap-search is special.. > > > We already have that, it’s ldap-filter. > > In more detail, ldap-filter takes an LDAP filter, for example > (objectclass=mailRecipient), and then it takes an r->user, for example > f...@example.com, and then it combines them to create a new filter > (&(uid=f...@example.com)(objectclass=mailRecipient)), and if exactly one (not > zero, not two) objects exist, it is a match. > > ldap-search ignores the r->user special case and broadens this to any > expression you can image. > > On a side note, ldap-search requires that exactly one LDAP object matches, we > might want to support many matches, or a specific > number of matches. > > > I still don't get where "Make sure that the filtered search returned a > single dn" is enforced, is it because result != LDAP_SUCCESS > otherwise, or dn == NULL if there are multiple objects/DNs? > > > It’s enforced here: > > https://github.com/apache/httpd/blob/trunk/modules/ldap/util_ldap.c#L2118 > > For historic reasons, the function is called uldap_cache_getuserdn(), but > what the function actually does is run a single LDAP query, and expect one > and only one object in return. > > ldap-search runs a single LDAP query, and expects one and only one object in > return, it just isn’t a user.
Thanks for the explanation. Regards; Yann.
