> Disabling the cache by default would be great. Thanks! > > EAP-Kerberos doesn't actually exist today as a documented spec -
Ah I guess I guess what I read wasn't an official IETF draft (it was years ago and I figured someone might have done something by now). > I'm sure that's why there's no client side code. I agree that it > would be very nice, not only for the SSO function, but also because > it would not be exposing the Kerberos password to the RADIUS > servers. Indeed. > > Many years ago, I tried to drum up interest in developing an > EAP-Kerberos spec in the IETF. Ultimately, it didn't go anywhere, > but you can read some of the discussion in the following archived > thread: > > http://www.ietf.org/mail-archive/web/secmech/current/msg00041.html Thanks :) > >>> 2) Although freeradius is multi-threaded, the Kerberos authentication >>> module is single-threaded. I believe recent versions of both >>> MIT and Heimdal Kerberos libraries are threadsafe, but I don't >>> think the freeradius code has been updated for this. So the only >>> way to scale the performance of the RADIUS infrastructure is to >>> deploy more servers (they don't have to by physical, you can install >>> multiple software instances on the same server if you have extra >>> CPUs or cores). >>> >>> We currently have 8 freeradius servers running on 4 physical >>> servers (2 per box). And we balance the wireless controllers >>> across those. >> >> As the university I used to work at, we were handling a similar load with >> two Xserve G5s, but we were using LDAP and not Kerberos. >> > > The LDAP module is multithreaded, right? That would give it an > advantage. Yes. > One other mistake we made was that our RADIUS server > hardware has many cores, but each core itself is quite slow - > this was before we found out that the freeradius krb5 module > was single threaded. If we'd known that earlier, we'd have instead > purchased machines with fewer faster cores. Additionally the control thread is also the only one that can insert packets into the request queue, though any worker can pick requests off it. >>> One of our staff members is also looking at patching freeradius >>> to multithread the Kerberos bits, but unless the freeradius >>> folks accept those patches and maintain them, we likely won't >>> deploy that option in production. >>> >> >> v2.1.x has gone into an unofficial feature freeze for anything not related >> to DHCP functionality. If you want this code to be included in function >> releases please submit the patches against the master branch (3.0). *future releases > Thanks! I'll pass this info along to our team! np -Arran ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
