On May 23, 2021, at 11:28 AM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
But let's look at slapd log for a good case (stripped a bit of syslog output to keep lines shorter): ... As you can see the SASL/EXTERNAL bind for searching the user entry and the simple bind operation for checking user's password is done within a single pooled LDAP connection (conn=1735). This leads to this LDAP session being bound to the end user's entity. But this end user is not authorized to do the searches for users!
Is that really how it is supposed to work?
Nope. That code hasn't changed in 3.0.22, so I'm not sure what's going on. Look for "rebound" in src/modules/rlm_ldap. If it binds a connection as a particular user, then it sets "rebound=true". And before using that connection again, it re-binds as the admin / read-only user.
In my own implementations I always have persistent pooled connections for searching the LDAP directory, typically to map input username to the bind-DN, but strictly open new temporary LDAP connection for each simple bind operation checking a user's password. For better performance the latter can also be a second pooled anonymous connection exclusively used to send bind operations for user password validation and nothing else.
It doesn't do exactly that, but pretty close.
BTW: For such a situation OpenLDAP 2.5 now has a new overlay which implements the so-called Verify Credentials extended operation with which you can check the user's password including password policy checks done by slapd without re-binding. This would also save round-trips. But it will probably take some time before 2.5 gets widely available.
Yes. Alan DeKok.