Hi, Using the default eap/peap & inner-tunnel configuration, a failure gives rise to this: Exec-Program output: Logon failure (0xc000006d) Exec-Program-Wait: plaintext: Logon failure (0xc000006d) Exec-Program: returned: 1 [mschap] External script failed. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject [eap] Freeing handler ++[eap] returns reject Failed to authenticate the user. } # server inner-tunnel [peap] Got tunneled reply code 3 MS-CHAP-Error = "\nE=691 R=1" EAP-Message = 0x040a0004 Message-Authenticator = 0x00000000000000000000000000000000 [peap] Got tunneled reply RADIUS code 3 MS-CHAP-Error = "\nE=691 R=1" EAP-Message = 0x040a0004 Message-Authenticator = 0x00000000000000000000000000000000 [peap] Tunneled authentication was rejected. [peap] FAILURE ++[eap] returns handled How can I take that MS-Chap-Error attribute and pass it back in the final access-reject, as a Reply-Message attribute for example. Cheers --Mike
Hi,
Hi, Using the default eap/peap & inner-tunnel configuration, a failure gives rise to this:
Exec-Program output: Logon failure (0xc000006d) Exec-Program-Wait: plaintext: Logon failure (0xc000006d) Exec-Program: returned: 1 [mschap] External script failed. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject [eap] Freeing handler ++[eap] returns reject Failed to authenticate the user. } # server inner-tunnel [peap] Got tunneled reply code 3 MS-CHAP-Error = "\nE=691 R=1" EAP-Message = 0x040a0004 Message-Authenticator = 0x00000000000000000000000000000000 [peap] Got tunneled reply RADIUS code 3 MS-CHAP-Error = "\nE=691 R=1" EAP-Message = 0x040a0004 Message-Authenticator = 0x00000000000000000000000000000000 [peap] Tunneled authentication was rejected. [peap] FAILURE ++[eap] returns handled
How can I take that MS-Chap-Error attribute and pass it back in the final access-reject, as a Reply-Message attribute for example.
unlang? set a variable to the value of MS-CHAP-Error and then set the Reply-Message to be some text with that variable in it. alternatively you could probably call PERL pr pythin etc at the right time and do the required variable and reply-message settings with those languages instead however....by sending such messages the remote user knows the reason for failure eg incorrect password but a successful user...and could bruteforce alan
unlang? set a variable to the value of MS-CHAP-Error and then set the Reply-Message to be some text with that variable in it.
Unfortunately, this sends it back in the next packet, which is an Access-Challenge, not in the final Access-Reject. Also, for some strange reason, the post-auth section in the inner-tunnel only gets called on a successful auth, not on a failure, so I can't output the failure to sql there either.
alternatively you could probably call PERL pr pythin etc at the right time and do the required variable and reply-message settings with those languages instead
however....by sending such messages the remote user knows the reason for failure eg incorrect password but a successful user...and could bruteforce I plan to do something along the lines of: MS-Chap-Error=User wrong => login failed MS-Chap-Error=PAss wrong => login failed MS-Chap-Error=Account locked => Account locked
--Mike
Michael Bryant wrote:
unlang? set a variable to the value of MS-CHAP-Error and then set the Reply-Message to be some text with that variable in it.
Unfortunately, this sends it back in the next packet, which is an Access-Challenge, not in the final Access-Reject.
Sending Reply-Message in an Access-Reject is not permitted for EAP sessions. It is also not supported by any NAS. What you want to do is impossible. Even if you get FreeRADIUS to send a Reply-Message, it will get ignored by the NAS and the client PC. As a result, the message will do *nothing* useful. Alan DeKok.
On 14/08/2009 07:51, Alan DeKok wrote:
Michael Bryant wrote:
unlang? set a variable to the value of MS-CHAP-Error and then set the Reply-Message to be some text with that variable in it.
Unfortunately, this sends it back in the next packet, which is an Access-Challenge, not in the final Access-Reject.
Sending Reply-Message in an Access-Reject is not permitted for EAP sessions. It is also not supported by any NAS.
Sending a Reply-Message is not permitted in any packet where an EAP-Message attribute is included.
What you want to do is impossible. Even if you get FreeRADIUS to send a Reply-Message, it will get ignored by the NAS and the client PC. As a result, the message will do *nothing* useful.
Depends on the NAS. But yeah, doing this breaks things. The best thing you can do is log the error in the post-auth section. If you want the users to fix the issues themselves, then it'd be pretty easy to write a small web app to look through the failure codes and convert them into something humanly readable. Arran -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Depends on the NAS. But yeah, doing this breaks things. The best thing you > can do is log the error in the post-auth section.
In V1 of FR, the rlm_mschap module used to create a Module-Failure-Message request attribute containing the output of ntlm_auth, if ntlm_auth failed (rlm_ldap does this too on user not found). This code was removed in V2. I've tried adding it back in but it doesn't work because in V2 another trip occurs after the failure. So, the Module-Failure-Message attribute no longer exists when the reject is issued. I'd like to capture the ntlm_auth output for logging purposes and need it available when the reject is sent. I've thought about storing it in the eap handler so it survives the next trip; but, I'm not sure if this is the best alternative. Does this seem like a reasonable solution or can you think of a better approach? Just to be clear, I'm not proposing sending this info back to the NAS, just capturing it for logging (so that if the user calls our help desk, they can determine why the authentication failed by looking in the log). Thanks for your advice..
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Garber, Neal -
Michael Bryant