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_at_zhegan.in> wrote in message
news:5225DD87.7060907_at_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.com_at_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.
>
Received on Tue Sep 03 2013 - 19:36:53 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 04 2013 - 12:00:05 MDT