Newbie question on caching Ldap-Group

Alan DeKok aland at deployingradius.com
Tue Apr 9 14:11:54 CEST 2019


On Apr 9, 2019, at 4:30 AM, Alexander Harm <contact at aharm.de> wrote:
> 
> That didn’t change anything. Can anyone comment on this?

  The short answer is to ensure that your LDAP server remains up.

> I have a probably stupid question regarding the caching of Ldap-Group. I've read rather confusing information on the net (like v3 caches Ldap-Group per default, it doesn't work for me) etc.

  v3 reads LDAP, and caches the LDAP-Group attribute for one request.  This means that it doesn't have to hit the LDAP server every time you do an LDAP-Group comparison.

> Contrary to most examples I want the cache to be the failover for LDAP. So if my LDAP server is down, group membership should be retrieved from cache.
> 
> sites-enabled/...
> 
> authorize {
> # read group membership from LDAP or cache
> update control {
> Cache-Status-Only = yes
> }
> redundant {
> ldap
> cache
> }
> update control {
> Cache-Status-Only := no
> }
> cache

  That's a little complex, and *always* updates the cache, even if the LDAP groups were read from the cache.

> mods-enabled/cache
> 
> update {
> # Cache LDAP group membership
> &control:Ldap-Group += &control:Ldap-Group
> }
> 
> While the fallback works, I'm a bit surprised to see the group information multiply in the cache:
> 
> (0) ldap: Waiting for search result...
> (0) ldap: Adding cacheable group object memberships
> (0) ldap:   &control:LDAP-Group += "AAD DC Administrators"
> (0) ldap:   &control:LDAP-Group += "ka.hq.all"
> (0) ldap:   &control:LDAP-Group += "ka.hq.portal"

  So you know what those attributes are and where they are located.

> (0) ldap: Processing user attributes
> (0) ldap: WARNING: No "known good" password added. Ensure the admin user has permission to read the password attribute
> (0) ldap: WARNING: PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure)
> rlm_ldap (ldap): Released connection (0)
> (0)       [ldap] = ok
> (0)     } # redundant = ok
> (0)     update control {
> (0)       Cache-Status-Only := no
> (0)     } # update control = noop
> (0) cache: EXPAND %{User-Name}
> (0) cache:    --> John.Doe
> (0) cache: No cache entry found for "John.Doe"
> (0) cache: Creating new cache entry
> (0) cache: EXPAND Cache last updated at %t
> (0) cache:    --> Cache last updated at Tue Apr  9 01:32:38 2019
> (0) cache:   &reply:Reply-Message += Cache last updated at Tue Apr  9 01:32:38 2019
> (0) cache: EXPAND %{randstr:ssssssssssssssssssssssssssssssss}
> (0) cache:    --> v9I9w/YhZ9zjjYCDwku8M1o2yY1EZtHj
> (0) cache:   &reply:Class := 0x76394939772f59685a397a6a6a594344776b75384d316f32795931455a74486a
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'ka.hq.portal'
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'ka.hq.all'
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'AAD DC Administrators'
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'AAD DC Administrators'
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'ka.hq.all'
> (0) cache:   control:Ldap-Group += &control:Ldap-Group[*] -> 'ka.hq.portal'
> (0) cache: Merging cache entry into request

  Which is likely not what you want.  i.e. if LDAP succeeds, you *don't* want to look at the cache.

> (0) cache:   &reply:Reply-Message += "Cache last updated at Tue Apr  9 01:32:38 2019"
> (0) cache:   &reply:Class := 0x76394939772f59685a397a6a6a594344776b75384d316f32795931455a74486a
> (0) cache:   &control:LDAP-Group += "ka.hq.portal"
> (0) cache:   &control:LDAP-Group += "ka.hq.all"
> (0) cache:   &control:LDAP-Group += "AAD DC Administrators"
> (0) cache:   &control:LDAP-Group += "AAD DC Administrators"
> (0) cache:   &control:LDAP-Group += "ka.hq.all"
> (0) cache:   &control:LDAP-Group += "ka.hq.portal"
> (0) cache: Committed entry, TTL 86400 seconds
> 
> Can I ignore this or did I setup something wrong?

  It's doing exactly what you told it to do.  If you want it to do something else, then configure it to do something else.

  Alan DeKok.




More information about the Freeradius-Users mailing list