How to bypass some logic during EAP-TLS auth?
Currently I have several if()s in authorize{} before eap and I think I can not move it past EAP call But during EAP authentication I see this logic gets executed 8(!) times in -X debug session. Can I wrap those if()s into some rule like "If session is new, then execute wrapped logic, else - just bypass wrapped block"? authorize { if (!(&NAS-Port-Type && &NAS-Port-Type == Wireless-802.11)) { update request { &Module-Failure-Message += 'Rejected: NAS-Port-Type is not Wireless-802.11.' } reject } rewrite_called_station_id if (!Called-Station-SSID) { update request { &Module-Failure-Message += 'Rejected: No SSID in Called-Station-Id' } reject } if ("%{client:vlan_for_%{Called-Station-SSID}}") { update session-state { Tunnel-Type := VLAN # rfc3580 Tunnel-Medium-Type := IEEE-802 #rfc2628 Tunnel-Private-Group-Id := "%{client:vlan_for_%{Called-Station-SSID}}" # string, rfc2628 } } else { update request { &Module-Failure-Message += "Rejected: No vlan_for_%{Called-Station-SSID} defined for client %{client:shortname}" } reject } if (!(&User-Name)) { update request { &Module-Failure-Message += 'Rejected: User-Name not provided.' } reject } eap_wifi { ok = return updated = return } } authenticate { eap_wifi }
On 02/11/2024 21:05, Alexey D. Filimonov wrote:
Currently I have several if()s in authorize{} before eap and I think I can not move it past EAP call
But during EAP authentication I see this logic gets executed 8(!) times in -X debug session.
Can I wrap those if()s into some rule like "If session is new, then execute wrapped logic, else - just bypass wrapped block"?
Use an attribute in the session-state list, which exists over all packets in the same session. It will be empty in the first request. authorize { if (!&session-state:Tmp-Integer-1) { update session-state { &Tmp-Integer-1 := 1 } ... stuff only the first time here ... } ... everything else here ... } -- Matthew
Hi guys Can I shortly catch up on this topic, because I have a similar use case as well: I add some missing RADIUS attributes on the first RADIUS request to the request packet and afterwards, this if block will not be hit anymore. Great hint with this session variable, thanks Matthew. A general question concerning this question: evaluating those if statements 8 times in the first place does not have any performance impact on FreeRADIUS, correct? I think it does not really matter, if FreeRADIUS has to do it. I know it would be more optimal to not have FreeRADIUS evaluate multiple attributes each time, but does it harm the overall performance noticeable? Thanks and regards Dominic Am 02.11.24, 22:11 schrieb "Freeradius-Users im Auftrag von Matthew Newton via Freeradius-Users" <freeradius-users-bounces+dominic.stalder=unibe.ch@lists.freeradius.org <mailto:unibe.ch@lists.freeradius.org> im Auftrag von freeradius-users@lists.freeradius.org <mailto:freeradius-users@lists.freeradius.org>>: On 02/11/2024 21:05, Alexey D. Filimonov wrote:
Currently I have several if()s in authorize{} before eap and I think I can not move it past EAP call
But during EAP authentication I see this logic gets executed 8(!) times in -X debug session.
Can I wrap those if()s into some rule like "If session is new, then execute wrapped logic, else - just bypass wrapped block"?
Use an attribute in the session-state list, which exists over all packets in the same session. It will be empty in the first request. authorize { if (!&session-state:Tmp-Integer-1) { update session-state { &Tmp-Integer-1 := 1 } ... stuff only the first time here ... } ... everything else here ... } -- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>
participants (3)
-
Alexey D. Filimonov -
dominic.stalder＠unibe.ch -
Matthew Newton