Hello Alan, I want logging information, if a client shows up with an expired certificate. Therefor in authorize I have: ... eap if ( invalid ) { update reply { Tmp-String-5="INVALID Certificate" } } .... in post-auth : .. Post-Auth-Type REJECT { sql_log } and in modules/sql_log: Post-Auth = "INSERT INTO ${postauth_table} \ (username, pass, reply, authdate, nasname, nasipaddress,radiusip,machinetype,nasport,modulefailmes,csi) VALUES \ ('%{User-Name}', '%{User-Password}', \ '%{reply:Packet-Type}', '%S', '%{NAS-Identifier}','%{Client-IP-Address}','${RADIP}',\ '%{Port-Message}','%{NAS-Port-Id}','%{reply:Tmp-String-5}','%{Calling-Station-Id}');" When a client shows up with an expired certificate I would expect to see the message "INVALID Certificate". ..... Here is what I get with 2.1.0: [tls] >>> TLS 1.0 Alert [length 0002], fatal certificate_expired TLS Alert write:fatal:certificate expired TLS_accept:error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned SSL: SSL_read failed in a system call (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. } # server cisco Using Post-Auth-Type Reject +- entering group REJECT {...} [sql_log] Processing sql_log_postauth expand: %{User-Name} -> HOST/osd02red.ww901.mycompany.net expand: %{%{User-Name}:-DEFAULT} -> HOST/osd02red.ww901.mycompany.net [sql_log] sql_set_user escaped user --> 'HOST/osd02red.ww901.mycompany.net' expand: INSERT INTO radpostauth (username, pass, reply, authdate, nasname, nasipaddress,radiusip,machinetype,nasport,modulefailmes,csi) VALUES ('%{User-Name}', '%{User-Password}', '%{reply:Packet-Type}', '%S', '%{NAS-Identifier}','%{Client-IP-Address}','1.2.3.4', '%{Port-Message}','%{NAS-Port-Id}','%{reply:Tmp-String-5}','%{Calling-Station-Id}'); -> INSERT INTO radpostauth (username, pass, reply, authdate, nasname, nasipaddress,radiusip,machinetype,nasport,modulefailmes,csi) VALUES ('HOST/osd02red.ww901.mycompany.net', '', 'Access-Reject', '2008-09-12 09:58:09', '','123.246.185.169','1.2.3.4', '','','','00-00-00-00-00-02'); It seems, "if (invalid) " is not entered and I don't see why. Norbert Wegener
Norbert Wegener wrote:
It seems, "if (invalid) " is not entered and I don't see why.
The default behavior for "invalid" is to stop processing the request. This can be changed by: eap { invalid = 1 } if ( invalid ) { ... I'm not sure the default behavior is really documented anywhere, unfortunately. Alan DeKok.
If fear not... eap { invalid = 1 } if (invalid) { update reply { Tmp-String-5="INVALID Certificate" } ... TLS_accept:error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned SSL: SSL_read failed in a system call (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. } # server cisco Using Post-Auth-Type Reject +- entering group REJECT {...} ... Alan DeKok schrieb:
Norbert Wegener wrote:
It seems, "if (invalid) " is not entered and I don't see why.
The default behavior for "invalid" is to stop processing the request. This can be changed by:
eap { invalid = 1 } if ( invalid ) { ...
I'm not sure the default behavior is really documented anywhere, unfortunately.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Norbert Wegener wrote:
If fear not...
Hmm... if this is in the "authenticate" section, then the rules are different. The authenticate section is processed by selecting *one* module / section from the list. That *one* module is processed. So if you have: authenticate { eap foo } Then "eap" is run for Auth-Type = eap. "foo" is not used, and any failure / noop / whatever of "eap" does NOT cause it to fall through to "foo". The solution is to wrap it in an Auth-Type block: authenticate { Auth-Type eap { eap { invalid = 1 } if ( invalid ) { ... } } foo } In this case, the "eap" *section* will be processed. The contents will be treated just as if they were being run in the "authorize" section. So the default action for "invalid" has to be changed in order for it to fall through, and continue processing. Alan DeKok.
Thanks, that works. Norbert Wegener Alan DeKok schrieb:
Norbert Wegener wrote:
If fear not...
Hmm... if this is in the "authenticate" section, then the rules are different. The authenticate section is processed by selecting *one* module / section from the list. That *one* module is processed.
So if you have:
authenticate { eap foo }
Then "eap" is run for Auth-Type = eap. "foo" is not used, and any failure / noop / whatever of "eap" does NOT cause it to fall through to "foo".
The solution is to wrap it in an Auth-Type block:
authenticate { Auth-Type eap { eap { invalid = 1 } if ( invalid ) { ... } } foo }
In this case, the "eap" *section* will be processed. The contents will be treated just as if they were being run in the "authorize" section. So the default action for "invalid" has to be changed in order for it to fall through, and continue processing.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Norbert Wegener