(Replies inline) On Thu, Apr 1, 2021 at 5:40 PM Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2021, at 7:08 PM, Braden McGrath via Freeradius-Users <freeradius-users@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