Massaging the behavior of LDAP-Group caching?

[Braden McGrath]

All,

I ran into a problem with LDAP-Group and a DN that it was not able to
find a friendly name for.
I have a function called "group_authz" (loaded from a file in
policy.d) that gets called in the post-auth{} section of my site.
The function just does a few if comparisons against &LDAP-Group[*] and
then updates the reply to the NAS with attributes.

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.

The group it choked on is something used internally by FreeIPA. It's
not a group I care about, and not user-created (it's not even visible
inside the standard FreeIPA interface). There are actually multiple
groups like this that I presume it will complain about, if it wasn't
failing at the first one.

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.

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"? 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").

If I have to just stick to matching on full DNs, I will... was just
trying to learn if there was a way to deal with this lookup failure
gracefully. :-)

Snippet of log output in the failure state is below... In this case, I
had cacheable_names=yes enabled, but I disabled caching later to test
further (caching itself isn't the problem, it's just the unresoveable
DN).

(0) ldap: Performing search in "cn=users,cn=accounts,dc=foobar,dc=org"
with filter "(uid=admin-person)", scope "sub"
(0) ldap: Waiting for search result...
(0) ldap: User object found at DN
"uid=admin-person,cn=users,cn=accounts,dc=foobar,dc=org"
(0) ldap: Resolving group DN
"cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org" to group name
(0) ldap: Performing unfiltered search in
"cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org", scope "base"
(0) ldap: Waiting for search result...
(0) ldap: Group DN "cn=admins,cn=groups,cn=accounts,dc=foobar,dc=org"
resolves to name "admins"
(0) ldap: Resolving group DN "cn=Replication
Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" to group name
(0) ldap: Performing unfiltered search in "cn=Replication
Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org", scope "base"
(0) ldap: Waiting for search result...
(0) ldap: Search returned no results
(0) ldap: ERROR: Group DN "cn=Replication
Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" did not resolve
to an object
rlm_ldap (ldap): Released connection (0)
Need 5 more connections to reach 10 spares
rlm_ldap (ldap): Opening additional connection (5), 1 of 27 pending slots used
rlm_ldap (ldap): Connecting to ldap://ipa1.foobar.org:389
ldap://ipa2.foobar.org:389 ldap://ipa3.foobar.org:389
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Bind successful
(0)     [ldap] = invalid
(0)   } # authorize = invalid
(0) Invalid user (ldap: Group DN "cn=Replication
Administrators,cn=privileges,cn=pbac,dc=foobar,dc=org" did not resolve
to an object): [admin-person] (from client dc-srv-
sw01 port 11526)
(0) Using Post-Auth-Type Reject

I appreciate any suggestions!
Cheers,
Braden