Hi Eugene,
I am curious about what you see. Could you do a traffic capture on port
88(Kerberos), 53(DNS) and 389(LDAP) ? In theory the acl helper does cache
results and depending on the caching you should see this delay only for the
first login of the user ( I accept it is too long).
The section you marked is where the Kerberos authentication for the ldap
connection happens. I use a memory cache and I think I can check if the
cache has a valid credential before re-authenticate.
Thank you
Markus
"Eugene M. Zheganin" <eugene@xxxxxxxxx> wrote in message
news:5225DD87.7060907@xxxxxxxxx...
Hi.
I moved almost all of my squid to authentication schemes using
ext_kerberos_ldap_group_acl, and, though they do work OK, I'm not
entirely happy with their performance. ext_ldap_group_acl is like speed
of light fast comparing to ext_kerberos_ldap_group_acl. The most lag
(around 0.5 sec) happens, from my observation, between these two lines:
[...]
support_krb5.cc(267): pid=53166 :2013/09/03 18:52:45|
kerberos_ldap_group: DEBUG: Got principal name
HTTP/proxy1.norma.com@xxxxxxxxx
support_krb5.cc(311): pid=53166 :2013/09/03 18:52:46|
kerberos_ldap_group: DEBUG: Stored credentials
[...]
Is there any way to speed this up ? I've reread the documentation, but
without result. Is there any cache that could be used ?
I understand that kerberos group helper is way more complicated than the
pure ldap one, but still, having this pause on each group membership
checking is sad.
Thanks.
Eugene.
