Newbie question on caching Ldap-Group

[Alan DeKok]

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.