Re: rlm_perl authentication override
Quoting tnt@kalik.net:
Is there a way to change the reply from Access-Reject, to Access-Accept?
Change freeradius.internal attribute Packet-Type in Post-Auth-Type Reject section.
Changing freeradius.internal Packet-Type from Access-Reject to Access-Accept would affect ALL logins - even logins which *should* be rejected. I'm referring to changing Access-Reject to Access-Accept under certain circumstances only -- not globally for all logins. ...or am I misunderstanding what you're suggesting? Thanks Henry
Changing freeradius.internal Packet-Type from Access-Reject to Access-Accept would affect ALL logins - even logins which *should* be rejected.
I'm referring to changing Access-Reject to Access-Accept under certain circumstances only -- not globally for all logins.
So check the "circumstances" before changing the Packet-Type. Ivan Kalik Kalik Informatika ISP
Quoting tnt@kalik.net:
So check the "circumstances" before changing the Packet-Type.
Of course, you are right :p, thanks. I'm wondering though: during that small window period when the Packet-Type is changed and returned, would it be possible that it would affect other sessions running concurrently (separate threads)? Presumably the changed Packet-Type would have a limited scope (ie, visible to the current executing thread/session only, and not others)? Regards Henry
Henry wrote:
I'm wondering though: during that small window period when the Packet-Type is changed and returned, would it be possible that it would affect other sessions running concurrently (separate threads)?
No. When you do an LDAP query for a request, or process a request through the "users" file, it doesn't affect other requests that are being processed. Alan DeKok.
Greetings, and thanks to Ivan and Alan for their feedback. I've been dumping variables, etc, in my rlm_perl script (using Devel::Symdump and Data::Dumper) trying to figure out where to change the Packet-Type from Access-Reject to Access-Accept without success. I've also gone over the rlm_perl.c file, etc, hoping something would jump out at me -- what I'm trying to do doesn't appear to be documented (for obvious reasons). I'm hoping someone on this list knows how to change the Packet-Type in a rlm_perl script. Any comments/pointers are appreciated. If I knew where to dig, I'd have at it. Thanks Henry
Perhaps if I try another approach: Using rlm_perl, if a request is received and I want to accept the login without performing any normal auth (in authorize()), what would I need to return? Constructing the $RAD_REPLY packet is no problem. What to return to force an Access-Accept has me stymied. RLM_MODULE_OK will lead to normal auth (and failure); RLM_MODULE_HANDLED results in no further processing (ie, no response is sent to the NAS); RLM_MODULE_UPDATED also proceeds to normal auth (and failure). RLM_MODULE_HANDLED seems to be the answer, but how do I first send the Access-Accept response in authorize() followed by "return RLM_MODULE_HANDLED;" to stop further processing? Unfortunately there isn't a RLM_MODULE_ACCEPT return value. Any pointers to relevant docs or comments would be appreciated. Thanks Henry
Quoting tnt@kalik.net:
Using rlm_perl, if a request is received and I want to accept the login without performing any normal auth (in authorize()), what would I need to return?
Auth-Type Accept.
Thanks Ivan. I eventually figured out by trial and error that the following needs to be done in authorize(): ... $RAD_CHECK{'Auth-Type'} = 'Accept'; return RLM_MODULE_OK; Cheers Henry
Hi, I am still waiting on the freeradius logs from the customer experiencing this problem, but I was wondering if anyone had ever seen the following before or have any ideas what may be causing it: 1. EAP-TTLS client sends the EAP-Identity (packet id 2) 2. EAP-TTLS client receives the EAP-TTLS-Start (packet id 2) 3. EAP-TTLS client sends the EAP-TTLS-ClientHello packet (packet id 3) 4. EAP-TTLS Client receives the EAP-TTLS-Start (packet id 4) Issues: 1. why is it receiving the EAP-TTLS-Start again 2. why is it receiving it with an incorrect packet id The customer does not have session resumption enabled and the config is very basic. Furthermore this does not happen all the time leading me to believe this might be a retransmit issue between the access point and freeradius, maybe during high load. Thanks, SecureW2
list@securew2.com wrote:
Furthermore this does not happen all the time leading me to believe this might be a retransmit issue between the access point and freeradius, maybe during high load.
That's likely. And since it's EAP retransmit after a long time, odds are that the RADIUS packet isn't retransmitted. It's a brand new RADIUS packet, which means that the RADIUS layer duplicate detection doesn't work. Which means that the EAP packet is processed again. I suspect that there's very little you can do about it. There are patches going into 3.0 which will detect RADIUS retransmits over multiple proxy hops. That is a rare case, but more likely in the case of eduroam. Fixing it is good. Alan DeKok.
Hi Alan, it still seems strange that it would respond with a packet id that was never sent by the client. I guess this could only happen if the AP somehow thought it should retransmit the identity request. I am hoping the radius server logs will help so i can see the missing packet causing freeradius to increment the packet id. Thanks, Tom
list@securew2.com wrote:
Furthermore this does not happen all the time leading me to believe this might be a retransmit issue between the access point and freeradius, maybe during high load.
That's likely. And since it's EAP retransmit after a long time, odds are that the RADIUS packet isn't retransmitted.
It's a brand new RADIUS packet, which means that the RADIUS layer duplicate detection doesn't work. Which means that the EAP packet is processed again.
I suspect that there's very little you can do about it.
There are patches going into 3.0 which will detect RADIUS retransmits over multiple proxy hops. That is a rare case, but more likely in the case of eduroam. Fixing it is good.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
list@securew2.com wrote:
it still seems strange that it would respond with a packet id that was never sent by the client. I guess this could only happen if the AP somehow thought it should retransmit the identity request.
Yes, maybe.
I am hoping the radius server logs will help so i can see the missing packet causing freeradius to increment the packet id.
As always, debug mode is useful. Alan DeKok.
On 19/11/12 16:27, Alan DeKok wrote:
There are patches going into 3.0 which will detect RADIUS retransmits over multiple proxy hops. That is a rare case, but more likely in the case of eduroam. Fixing it is good.
Ooh, really? What solution did you hit on?
Phil Mayers wrote:
Ooh, really? What solution did you hit on?
Cache reply by "State". authorize { cached_reply ... } post-auth { ... cached_reply } It returns "handled" in the "authorize" section if it finds a matching State. On authorize it does: if (cache[request State]) { send cached reply attrs handled } On post-auth it does: cache[request State] = 0 cache[reply State] = reply attrs It should work, I think. So if you have an intermediate proxy fail, the RADIUS re-transmit won't hit. But this will catch the retransmitted packet, which has the same State as a previous reply. Alan DeKok.
participants (5)
-
Alan DeKok -
Henry -
list＠securew2.com -
Phil Mayers -
tnt＠kalik.net