I am new to this community. In case I am doing something wrong, please let me know.
We are using in our keycloak realms with “LDAP user storage provider” in “User Federation”. Using that we have configured our LDAP settings, including some mappings.
My question is about the “Cache Settings” at the bottom of a LDAP user storage provider.
We can setup different options. By default is “DEFAULT” selected.
My are questions are:
What means “DEFAULT”? Esspecially how often and when will cached items invalidated?
When is “EVICTED_DAILY” running? At a specific timestamp or just a some point in time of a day after 24 hours?
Which documentation is explaining the behaviour for the LDAP caches? The best what I at least found is " Configuring an LDAP user storage provider" in Server Administration Guide
I would be interested as well, specially 'cause I see that even after setting the cache policy to MAX_LIFETIME, I still Keycloak always going to Active Directory. Would be really nice if there was a deeper explanation of how this caching works.
Hi all!
I’d like to bump up this topic.
As we can see in documentation for v6: https://www.keycloak.org/docs/6.0/server_admin/#storage-mode
"This approach also reduces load on the LDAP server as uncached users are loaded from the Keycloak database the 2nd time they are accessed. The only load your LDAP server will have is password validation. "
In latest version it is some different: https://www.keycloak.org/docs/latest/server_admin/#storage-mode
“Passwords are never imported. Their validation is always delegated to the LDAP server. The benefits of this approach is that all Keycloak features will work as any extra per-user data that is needed can be stored locally.”
So, documentation states that KC goes to AD always only for passwords.
But for ex. request /auth/admin/realms/TestRealm/groups/59d6c2c6-747d-41d7-9118-2442538c296b/members causes 3 records in AD logs. And some other requests too.
Why Keycloak doesn’t use it’s cache?
I’m experiencing the same thing here. I have setup an alternate authentication flow with OTP, so I can validate users even if the Keycloak server cannot connect to the remote AD server.
Unfortunately, I cannot even list the AD users once I disconnect the VPN connection.
Is there a magic switch to make the cache take precedence before connecting to AD?
Okay, now I’m seeing a little bit clearer. There are obviously some functions in the authentication flow that will use the local cache, while others go directly to the LDAP provider.
As the documentation states, the password will always be checked against LDAP. As I found out, fetching whole UserModel objects (session.users().getUsersStream(...)) or checking for attributes (session.users().searchForUserByUserAttributeStream(...)) will also query LDAP and not the local storage. User names and E-Mail will be taken from the cache, but will raise an exception if the user is not in the cache and the connection to Active Directory is off line.
Since I am looking for users by name, e-mail or attributes, I’m now doing this:
Query by name session.users().getUserByUsername(...)
Query by e-mail session.users().getUserByEMail(...)
Query by attribute session.userLocalStorage().searchForUserByUserAttributeStream(...)
Each of these steps is enclosed by try {...} catch, so that an exception caused by the AD not being available will pass silently. Note that in step 3 I’m using the userLocalStorage in order to bypass LDAP and query the attributes stored in the local database.
Maybe this will keep someone else’s hair from turning as grey as mine…
Alas, the path to happiness is still blocked. My modified User Form will identify and select the correct user, but if the LDAP connection is not available, the flow still does not continue.
Unexpected error when handling authentication request to identity provider.
The message says it all. The LDAP Storage Provider does not expect errors when requesting data from the identity provider. Since the identity provider is an external service, you simply have to expect trouble coming your way.
Now, there is nothing in my authentication flow for which communication with LDAP would be mandatory, but it simply does not execute.
I guess I will have to dig into the LDAP Storage Provider…
