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. Regards, Graham —
