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.