Newbie question on caching Ldap-Group

[Alexander Harm]

Thanks for your reply but I fear I still don’t understand it.

I rewrote my authorization part to

    ldap {

        fail = 1

    }

    if (fail) {

        update control {

            Cache-Status-Only = yes

        }

    }

    cache



I hope that is more to your liking.

But I still don't understand why it doubles the group info in the cache module. From man unlang

:=
    Add the attribute to the list. If any attribute of the same name is already present in that list, its value is replaced with the value of the current attribute.

so I put

&control:Ldap-Group := &control:Ldap-Group[*]

in the cache module.

(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"
(0) ldap: Processing user attributes

becomes

(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'

Why? Where do I tell the module to do just that?
On 9. April 2019 at 14:12:35, Alan DeKok (aland at deployingradius.com) wrote:

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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html