Module-Failure-Message when using PEAP or TTLS
Hello, When using EAP PEAP or TTLS, if I try to write the '%{Module-Failure-Message}' in the post-auth section to SQL, the value is blank when the reason is incorrect password. When using a non-tunnelled authentication protocol, it correctly displays 'rlm_pap: CLEAR TEXT password check failed' I think I know why this is happening, because the rejection happens prior to the last message in the EAP sequence, so the value of the module-failure-message is no longer populated in the last message sent to the device, which is when the post-auth is done. And I have read somewhere that using the caching feature can cache the value of the module-failure-message at the point of it happening, and then retrieve it when the post-auth is done. But I can't see to find any examples how to do this specifically using the cache feature. Does anyone have a working example of this they would like to share with me please? Thanks
On Dec 8, 2014, at 7:08 AM, Dean Goldhill <dgoldhill@netutils.com> wrote:
When using EAP PEAP or TTLS, if I try to write the ‘%{Module-Failure-Message}’ in the post-auth section to SQL, the value is blank when the reason is incorrect password. When using a non-tunnelled authentication protocol, it correctly displays ‘rlm_pap: CLEAR TEXT password check failed’
In v3.0.5, you need to cache the Module-Failure-Message - in inner-tunnel, post-auth-type Reject, do: update outer.session-state { Module-Failure-Message := &request:Module-Failure-Message } And then in the “default” virtual server, post-auth section, you can use: %{%{session-state:Module-Failure-Message}:-%{Module-Failure-Message}} Which says “use the saved message from the inner tunnel, but if that doesn’t exist, use the failure message from the outer session”.
I think I know why this is happening, because the rejection happens prior to the last message in the EAP sequence, so the value of the module-failure-message is no longer populated in the last message sent to the device, which is when the post-auth is done.
Yes. Alan DeKok.
Hello, I am sorry that I didn't mentioned that I am running FR 2, not 3. When I try your example, I get a startup error: Module: Checking post-auth {...} for more modules to load /etc/raddb/sites-enabled/inner-tunnel[303]: Unknown attribute list "outer.session-state" /etc/raddb/sites-enabled/inner-tunnel[303]: Failed to parse "update" subsection. I assume this only works in version 3? -----Original Message----- From: freeradius-users-bounces+dgoldhill=netutils.com@lists.freeradius.org [mailto:freeradius-users-bounces+dgoldhill=netutils.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 08 December 2014 15:37 To: FreeRadius users mailing list Subject: Re: Module-Failure-Message when using PEAP or TTLS On Dec 8, 2014, at 7:08 AM, Dean Goldhill <dgoldhill@netutils.com> wrote:
When using EAP PEAP or TTLS, if I try to write the '%{Module-Failure-Message}' in the post-auth section to SQL, the value is blank when the reason is incorrect password. When using a non-tunnelled authentication protocol, it correctly displays 'rlm_pap: CLEAR TEXT password check failed'
In v3.0.5, you need to cache the Module-Failure-Message - in inner-tunnel, post-auth-type Reject, do: update outer.session-state { Module-Failure-Message := &request:Module-Failure-Message } And then in the "default" virtual server, post-auth section, you can use: %{%{session-state:Module-Failure-Message}:-%{Module-Failure-Message}} Which says "use the saved message from the inner tunnel, but if that doesn't exist, use the failure message from the outer session".
I think I know why this is happening, because the rejection happens prior to the last message in the EAP sequence, so the value of the module-failure-message is no longer populated in the last message sent to the device, which is when the post-auth is done.
Yes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 9, 2014, at 5:48 AM, Dean Goldhill <dgoldhill@netutils.com> wrote:
I am sorry that I didn't mentioned that I am running FR 2, not 3.
Then there isn’t much you can do, sorry. Your options are limited to storing the Module-Failure-Message in a database (or log file), when it’s seen in the “inner-tunnel” virtual server. Alan DeKok.
participants (2)
-
Alan DeKok -
Dean Goldhill