Massaging the behavior of LDAP-Group caching?

[Alan DeKok]

On Apr 1, 2021, at 7:48 PM, Braden McGrath <braden at 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.  :(

> 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 LDAP-Group attribute is cached.  So it won't do DB queries for every unlang operation.  You can check this by running in debug mode.

> I appreciate all of the support, and thank you and the rest of the FR
> contributors for the entire project.

  Thanks.

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

  Exactly.  There's no button labelled "do what I want".  :(

  RADIUS does

(WiFi, DSL, Dial-up, VPN) * (EAP-TLS, TTLS, PEAP, PAP, CHAP, MS-CHAP) * (VLAN, IP assignment) * (LDAP, SQL, Active Directory, ...)

  The combination makes life almost impossible.

  For what it's worth, I know that a popular Open Source DNS server looked into implementing DHCP.  After all, they wrote a complex DNS server, how hard can it be to do DHCP?

  They got told to look at FreeRADIUS for policies, not ISC.  After looking at FreeRADIUS, and the complex policies we support, the DNS guys gave up and decided to stick with DNS.

  Doing a complex, fast, policy server is *hard*.  People use DNS, and expect that that they can do the equivalent to "drop in a zone file, and it just works".  This is very, very, far from the truth.

  In other news, we're looking into implementing DNS in v4.  :)  It might be ~3K LoC to do the 99% of DNS that most people need.  Because all of the policies, configuration file reading, and network IO is already abstracted.

  i.e. if you build a complex policy server which plugs into every possible database, then *any* networking protocol is easy.

  Alan DeKok.