Newbie question on caching Ldap-Group
Hello, 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. 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 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" (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 (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? Thanks for your input, Alexander
I should probably use “:=” instead of “+=”… On 9. April 2019 at 01:51:27, Alexander Harm (contact@aharm.de) wrote: Hello, 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. 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 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" (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 (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? Thanks for your input, Alexander
That didn’t change anything. Can anyone comment on this? Thanks a lot. On 9. April 2019 at 01:58:12, Alexander Harm (contact@aharm.de) wrote: I should probably use “:=” instead of “+=”… On 9. April 2019 at 01:51:27, Alexander Harm (contact@aharm.de) wrote: Hello, 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. 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 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" (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 (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? Thanks for your input, Alexander
On Apr 9, 2019, at 4:30 AM, Alexander Harm <contact@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.
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@deployingradius.com) wrote: On Apr 9, 2019, at 4:30 AM, Alexander Harm <contact@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
participants (2)
-
Alan DeKok -
Alexander Harm