On Tue, Sep 25, 2012 at 09:49:53PM +0100, Matthew Newton wrote:
On Tue, Sep 25, 2012 at 06:08:04PM +0100, Phil Mayers wrote:
I did think about this myself; one option is to call rad_postauth manually if rad_authenticate(fake) fails in peap.c - which I guess is the easy/obvious solution you're referring to? Certainly preferable to the current situation IMO.
Yes. I'm just testing that to see if it behaves as expected - will post a patch for discussion if it seems OK.
Righto, finished hacking something together on master - pushed it to https://github.com/mcnewton/freeradius-server/commits/rad_virtual_server There are three small commits - 1. move rad_postauth (for accept) from the end of the rad_authenticate function to next to the rad_postauth called for reject in process.c. This means that rad_authenticate never calls rad_postauth - it always has to be called explicitly. 2. Add a new function, 'rad_virtual_server', which does everything needed to run a virtual server. In this case, calling rad_authenticate, and then rad_postauth. It could be easily expanded in future to also handle acct packets, although I can't quite think of a reason to at the moment (maybe for the rlm_inject idea?...) 3. Update PEAP/EAP_TLS/TTLS to call rad_virtual_server, rather than rad_authenticate. This means the inner-tunnels get a post-auth REJECT as well. I've tested it with successes and failures for PAP, EAP-TLS (check-eap-tls), PEAP and EAP-TTLS (inner-tunnel), and all work as expected. The only thing I'm slightly unsure about is (1) - it seems to behave as expected, and seems the right place to put it, but I'm not 100%. On why rad_postauth was previously removed from rad_authenticate for rejects, my guess would be that there are so many places that rad_authenticate return for a reject, it would be called from several places. It's just tidier to do an if() and call it once after rad_authenticate has returned. rad_postauth is called immediately on failure, so reject_delay doesn't seem the right reason. But that's just my guess. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>