I connected the company LDAP (AD) to my realm in kc 22. However, I noticed that in the user section the default search is slow (the attribute search doesn’t work). I tried both searching for the username and the email. Sometimes the user appears immediately, other times it takes a while. I don’t understand why, also because if I always search for the same user, should it be using the cache or am I wrong? I’ve noticed other delays during login (but I don’t know if it always has something to do with LDAP). What can I check?
this is my config:
I would enable Debug log for ldap package and also try to disable „always read from ldap“ in every mapper. Then enable the caching mechanism.
Then you can determine what is really slow.
Also try to login, if that is really slow, normally the ldap is the problem.
2 Likes
In what I have observed (and was also written in some issue), it doesn‘t affect the performance, if you use „always read value from ldap“ or not. It‘s only if the data should be used from LDAP or from the DB.
Keycloak does always when accessing a user, do a LDAP lookup to check if the user still exists and if the user is active. During this, all attributes for which a mapper exists, will be retrieved. The mapper just tells KC to use which value. Strange, In know.
Using a proper connection pooling can speed up a lot of things. But connection pooling should be enabled by default in recent versions (don‘t know about 22, which is already 2 years old, btw!!!)
And I also second, that most of the times the LDAP is the slow system, not Keycloak. Most of the times, not always…
The problem actually recurred. I also enabled connection pooling (there’s a button in the GUI on the 22). From the logs I see:
===== Pool start ======================
maximum pool size: 1000
preferred pool size: 5
initial pool size: 1
current pool size: 0
====== Pool end =====================
but still the search is slow, randomly.
Enable tracing and see what the root cause for slow searches are. Is e.g. Keycloak waiting for a LDAP response? Then, it’s not Keycloak, it’s LDAP…
I’ve had this once with a customer who has a cluster of 3 LDAP nodes behind of an LDAP proxy. Every time the proxy routed the Keycloak requests one particular node, the responses were slow and lead to a timeout. It was one of these backend LDAP nodes which was not properly configured and caused the delay.
Keycloak Tracing helped us a lot to debug this and find the root cause.