On Thu, Aug 23, 2012 at 08:18:18AM +0100, Arran Cudbard-Bell wrote: > So an interesting question would be - is anyone actually using > EAP-Kerberos? If not, i'll disable caching by default and add a note > to the configuration. AFAIK no supplicant has actually implemented > any of the client side infrastructure to distribute tickets to other > applications. It's annoying, SSO where you got your TGT from an > 802.1X authentication would be really neat.
Disabling the cache by default would be great. Thanks! EAP-Kerberos doesn't actually exist today as a documented spec - 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. 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 > > 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. 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. > > 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). > > If the module uses long lived connection handles, it must use the connection > API (src/main/connection.c). rlm_rest, rlm_sql and rlm_ldap2 (still in > development) do this already, and all modules will be updated in time. > > If the patches are well formatted, documented, and non-duplicative we'll > almost certainly accept them. > > -Arran Thanks! I'll pass this info along to our team! --Shumon. -- Shumon Huque University of Pennsylvania. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
