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" <eug...@zhegan.in> wrote in message news:5225dd87.7060...@zhegan.in...
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....@norma.com
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.



Reply via email to