Massaging the behavior of LDAP-Group caching?

[Braden McGrath]

(Replies inline)

On Thu, Apr 1, 2021 at 5:40 PM Alan DeKok <aland at deployingradius.com> wrote:
> On Mar 31, 2021, at 7:08 PM, Braden McGrath via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> > I ran into a situation where one of the groups it pulled from a user's
> > memberOf list "did not resolve to an object," which then causes
> > rlm_ldap to return "invalid" and thus rejects the whole attempt.
>
>   It's difficult to know what to do here.  The "right thing" isn't always clear.  Especially when the server has to work across multiple different LDAP servers.
>
>   The simple answer is that FreeIPA is broken, and is returning the wrong things.  It shouldn't be returning memberOf fields which don't resolve.  That just doesn't make any sense.
I was thinking the same way... I suspect it's something LDAP
permissions-related, where those groups are only used internally by
FreeIPA. If they are "internal," presumably 389DS (the underlying LDAP
server for FreeIPA) doesn't normally expect a "user" (or even a
"service" account, which is what my FR server is using) to query for
details on those groups, hence it is denying access. I need to go play
with ldapsearch to confirm that.

I don't think I want to follow the permission rabbit-hole I'd need to
"unhide" these groups from the FR LDAP credentials, though... I guess
it depends on what other security implications this might have.
Research required.

> > Or, is there a
> > way to get the LDAP-Group lookup process to only attempt to resolve
> > DNs that match a specified base/filter? The base_dn in the group{}
> > stanza of the ldap module is already set to the portion of the tree I
> > care about, but LDAP-Group seems to still try to resolve the DNs that
> > aren't in that base (presumably because it's just reading them from
> > "memberOf").
>
>   Yes, that's what it's doing.
I guess another option would be to comment out membership_attribute,
but this then requires FR to walk through all the groups looking for a
match based on the CN, which is obviously going to be slower than just
pulling the group list from memberOf. But since I know all of the
groups I'd be searching for will be readable, it should never get to a
state where it fails the search (unless I fat-finger the group name in
the FR config).

If I disable membership_attribute and fall back to membership_filter
and the ensuing string of queries, are those still cached by
cacheable_name or cacheable_dn so it doesn't have to run the lookups
for each unlang comparison?

>   The simple answer is to fix FreeIPA.  Or, to use the full DN as you've done.
I'll dig into FreeIPA a little further, but this may be "by design"
and "fixing" might not be worth the headache, especially when using
the full DN works. ;-) I can always set up some variables to make it a
little more readable.

I appreciate all of the support, and thank you and the rest of the FR
contributors for the entire project.
As a RADIUS noob, it's... a bit overwhelming at times, but the
documentation *is* pretty darn thorough. (I've seen much worse from
paid vendors of unrelated products!) It's not FR's fault that the
protocol is complicated and a little strange, and your users are all
trying to do thousands of different things with millions of different
systems. :-)

Regards,
Braden