[seems somewhat more appropriate on -devel, moving there] On Wed, Aug 05, 2009 at 01:11:33PM -0400, John Morrissey wrote:
I'm in the process of replacing OSG's Radiator with FreeRADIUS. I have our relatively complex configuration mostly ported, but a few things have left me stumped.
I'd like to write authentication failures to an SQL database using a detail listener so they're buffered, as with accounting:
detail detail.auth { detailfile = ${radacctdir}/detail-auth detailperm = 0600 header = "%t" }
post-auth { Post-Auth-Type REJECT { detail.auth } }
server buffered-sql-auth { listen { type = detail filename = ${radacctdir}/detail-auth load_factor = 100 } post-auth { sql } }
Detail entries are picked up by the listener, but it never seems to do anything with them:
Going to the next request Waking up in 0.7 seconds. Polling for detail file /var/log/freeradius/radacct/detail-acct Polling for detail file /var/log/freeradius/radacct/detail-auth detail_recv: Renaming /var/log/freeradius/radacct/detail-auth -> /var/log/freeradius/radacct/detail-auth.work detail_recv: Read packet from /var/log/freeradius/radacct/detail-auth.work Packet-Type = Access-Reject Framed-Protocol = PPP Service-Type = Framed-User Framed-IP-Address = 255.255.255.254 Framed-Compression = Van-Jacobson-TCP-IP Framed-MTU = 1500 Acct-Delay-Time = 0 server buffered-sql-auth { } # server buffered-sql-auth Finished request 7. Cleaning up request 7 ID 41800 with timestamp +263
It looks like detail_recv() explicitly sets its RAD_REQUEST_FUNP to rad_accounting:
*pfun = rad_accounting;
I haven't looked much into the FreeRADIUS source yet; is it reasonably easy to determine/loop through the configured handlers for the detail listener to support a situation like this? Is there a better way of doing this?
To restate, my goal is to write failed authentication detail to a detail log that's then read by a detail listener and inserted into an SQL database. Looking at the code, I was thinking about adding an intermediate function that would call both rad_accounting() and rad_postauth(). Since default_component_results[] indicates NOOP for both of these, this should be straightforward. The problem now becomes that the post-auth rlm_detail is writing the RADIUS *response* to the detail log, since that's the packet that's being handled at that point. rlm_detail can't be listed in authenticate {}, so I can't use unlang to only call rlm_detail on Access-Reject. Modifying rlm_detail to have an authenticate handler seems... dirty. Any ideas? Is there a better way to accomplish failed auth buffered SQL insertion? john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__