Massaging the behavior of LDAP-Group caching?

[Alan DeKok]

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 able to work around the problem by trying to match on the full
> DN instead of the friendly name, but this is obviously a bit harder to
> read in the config, and I'd prefer to use the friendly names if I can
> find a way to make it work.

  Sure.

> Is there a way to tell LDAP-Group to ignore any DN that it finds that
> it can't "resolve", instead of throwing an "invalid"?

  There's no configuration option for that, sorry.

> 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.

  The simple answer is to fix FreeIPA.  Or, to use the full DN as you've done.

  Alan DeKok.