I use an LDAP backend, and I still want this "ban" feature and am willing to pay for it (and implement it :).
I guess if/when I get hit with performance problems, I will look into those too, so maybe I will be hoisted on my own petard, or maybe the ldap backend will get optimized as a secondary effect of me adding this feature! Chris On 2011/07/25 13:08, Nico Williams wrote: > On Jul 25, 2011 11:37 AM, "Greg Hudson" <ghud...@mit.edu > <mailto:ghud...@mit.edu>> wrote: > > On Sun, 2011-07-24 at 17:30 -0400, Nico Williams wrote: > > > For performance reasons? It's like this forever, so there may not be > > > a performance reason anymore. IMO this should be fixed. > > > > I think performance is still an issue. We definitely still get feedback > > about the number of LDAP queries per KDC operation, and TGS requests are > > more frequent than AS requests. (At least, they should be. It depends > > on how often the KDC is used purely as a password verifier.) > > For LDAP the kdc ought to be async and/or multi-processed/threaded. > Yeah, I know, it's not, but that's not my problem or that of anyone not > using the LDAP backend. > > Also, IIRC LDAP has a method by which to request cache entry > invalidation updates. Maybe the LDAP backend ought to cache, which > would be no worse than not doing the client principal lookup in the TGS > case, and if you can quickly invalidate cached entries, that's a win. > > IMO making this change would be a win. > > Nico > -- > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos