Recording Module-Failure-Message when using PEAP
I’m attempting to store the module-failure-message in the authenticate section: authenticate { Auth-Type MS-CHAP { mschap { reject = 1 ok = 1 } if (!ok) { if (Module-Failure-Message) { update reply { Reply-Message += "%{Module-Failure-Message}" } } } eap } (I’ve also tried stashing the attribute in the control list, and also a few different attributes). However, once the post auth section is invoked, the attributes are no longer present. It seems the extra Access-Challenge -> Access Request before the reject is sent when using PEAP is wiping the state clean(?), so I’m unsure how to persist attributes so they can be logged in post auth. Is this unintentional behaviour, or is my config wrong? Also, there seems to be some memory corruption loading the "server" block in the debug output: "server { # from file p.�{�". Regards, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Adam Bishop wrote:
It seems the extra Access-Challenge -> Access Request before the reject is sent when using PEAP is wiping the state clean(?), so I’m unsure how to persist attributes so they can be logged in post auth.
See the "cache" module. You can cache attributes, and later read them out of the cache.
Is this unintentional behaviour, or is my config wrong?
It's just the way the server works. The only way to track information between packets is via a DB, or the cache module.
Also, there seems to be some memory corruption loading the "server" block in the debug output: "server { # from file p.�{�".
That was fixed a while ago. Alan DeKok.
On 29 May 2014, at 14:40, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
See the "cache" module. You can cache attributes, and later read them out of the cache.
I’ll give the cache module a try, I seem to recall though (this was a while ago since I last touched the cache module, so the code may have changed since) the cache module couldn’t be invoked in the "authenticate" section?
It's just the way the server works. The only way to track information between packets is via a DB, or the cache module.
I guess there’s no reason I need to have the failure message logged with the post-auth event - a separate failure log would work just as well. I’ll try that too. Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 29 May 2014, at 15:56, Adam Bishop <Adam.Bishop@JA.NET> wrote:
On 29 May 2014, at 14:40, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
See the "cache" module. You can cache attributes, and later read them out of the cache.
I’ll give the cache module a try, I seem to recall though (this was a while ago since I last touched the cache module, so the code may have changed since) the cache module couldn’t be invoked in the "authenticate" section?
That's what section overrides are for... cache.authorize -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Adam Bishop -
Alan DeKok -
Arran Cudbard-Bell