I had one very minor thing I ran across during troubleshooting that hopefully someone can answer, but after that question I'm going to provide my results of a deeper dive and "final solutions" for the list archive. When membership_attribute is set, and cacheable_name = yes, the ldap module pops this message in debug output during an access-request: ldap: Adding cacheable user object memberships ldap: &control:LDAP-Group += "foo" [etc, one line per group] ldap: Skipping caching group objects as directive 'group.membership_filter' is not set But later, when actually running an unlang compare against &LDAP-Group[*], FR says: User found. Matched cached membership The comments in the ldap config imply that membership_filter and membership_attribute aren't normally used simultaneously. :) I wasn't seeing additional queries during the actual unlang comparison, so I trust the message that it "Matched cached membership," but that leaves me confused about what "skipping caching group objects as directive 'group.membership_filter' is not set" meant. Anyway, here's my attempt at "Wisdom of the Ancients" (see https://xkcd.com/979/), in case anybody else is trying to tie FreeRADIUS to FreeIPA / 389DS... On Fri, Apr 2, 2021 at 7:08 AM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 1, 2021, at 7:48 PM, Braden McGrath <braden@big-geek.net> wrote:
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.
Then 389DS shouldn't be returning them. :(
FreeIPA / 389DS returns the "unfiltered" contents of a DN's "memberOf" attribute, even if the LDAP bind account in use doesn't have the ability to directly access each of the individual DNs listed in that attribute. In other words, it will *return* the list of everything a user is a "memberOf," but it won't necessarily allow you to pull more details about each of those DNs (like the friendly name). I don't know enough about LDAP to know if this is "correct" behavior for the memberOf attribute or not, but it's how 389DS seems to work. :) By default, an account able to bind to a FreeIPA server *can* pull all of the groups and users out of the "cn=accounts,dn=example,dn=org" tree. But, FreeIPA uses other sub-trees (cn=pbac and cn=hbac and probably a few more) in order to store its own permissions and other Magic, and a typical bind account with no extra privileges does _not_ have the ability to read those other sub-trees and return the actual names of the groups. A test with ldapsearch will get you a result of "0 Success" with a "numResponses: 1" but no actual LDAP Entries (i.e. no usable data) in the response. FR will Have A Bad Time if it attempts to query those permission groups for short names and gets blank stares from FreeIPA/389DS LDAP server. So, you need to be able to read them *if* you are using friendly/short name matches. (You can ignore all of this if you match on the full DN, because FR doesn't waste its time trying to turn the contents in memberOf into friendly names if it seems like you're doing a full DN match.) Long story short, as long as you don't mind the bind account you're using having *read* access to the names and other details of those FreeIPA permissions / etc, you can add a "Role" of your own naming in FreeIPA, grant it the permission "RBAC Readers" (this is a predefined permission in FreeIPA), and then assign that role to your LDAP bind account(s). The bind account will then be able to read all of the names on these otherwise "hidden" permission groups, and things should work. ;) If you don't want the bind account to have permissions to read about... permissions, the other option is to comment out membership_attribute and use membership_filter *instead*. In this case, FR walks through the group tree, and checks to make sure the user is in each of the groups. In many cases this is probably slower. However, if the user has a lot of these hidden FreeIPA permission groups (which are not part of the normal user-defined groups container/tree, and hence wouldn't be walked when using membership_attribute), and you do _not_ have many user-created groups, the membership_filter may actually have *fewer* LDAP queries involved. Personally, I'm just leaving my config with full DN matches, but I also granted the above role on the bind account in case I ever need to move to friendly name matches in the future. Good luck!