[Help] Is that possible to change the reject message that appears at the Windows Pop Up
Hi All, So i have been able to authenticate my wireless user using 802.1x + LDAP + MAC address (using CallingStationID attriubute). So now for example when user A have MAC 11:22:33 but tried to login using another device there will be a pop up window when they try to connect - just a plain error popup saying "Unable to connect". Is there any way we can customize this error from radius? or should be from the wireless AP? So below is the unlang code that i use to check whether the user have a set of MAC address in their ldap profile or not if(!control:Calling-Station-Id){ reject } Possible to have that reject command to return some code that Windows client can understand like "No MAC address" etc? Thanks in advance Danny -- Best Regards, Danny
On 18.03.2013 16:48, Danny Kurniawan wrote:
Hi All,
So i have been able to authenticate my wireless user using 802.1x + LDAP + MAC address (using CallingStationID attriubute). So now for example when user A have MAC 11:22:33 but tried to login using another device there will be a pop up window when they try to connect - just a plain error popup saying "Unable to connect". Is there any way we can customize this error from radius? or should be from the wireless AP?
So below is the unlang code that i use to check whether the user have a set of MAC address in their ldap profile or not if(!control:Calling-Station-Id){ reject }
Possible to have that reject command to return some code that Windows client can understand like "No MAC address" etc?
Thanks in advance Danny
you could send back a reply-message. But it is forbidden if you are doing EAP. And anyway, Micro$oft is not paying attention to it and will disregard it. so no, you can't send a message to the user. Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
hi, we would all love to be able to send a relevant error message to our clients if they fail to authenticate (either locally or remotely). but we cant. :-( alan
Thanks a lot :) Well i guess we just have to live with it :) -Danny On Tue, Mar 19, 2013 at 12:07 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
hi,
we would all love to be able to send a relevant error message to our clients if they fail to authenticate (either locally or remotely). but we cant. :-(
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Best Regards, Danny
On 18 Mar 2013, at 12:07, A.L.M.Buxey@lboro.ac.uk wrote:
hi,
we would all love to be able to send a relevant error message to our clients if they fail to authenticate (either locally or remotely). but we cant. :-(
The old HP switches used to convert the Reply-Message into an EAP-Notification and send it after the EAP-Success or EAP-Failure. The native OSX supplicant used to log this even though it never displayed it to the user. The Windows supplicant ignored it completely. WPA_Supplicant restarted authentication and went into an infinite authentication loop. It may be possible to send it before the EAP-Success/EAP-Failure message for some EAP methods, but chances are not all supplicants will like it, and most probably won't display anything. -Arran
On Mon, Mar 18, 2013 at 8:42 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
The old HP switches used to convert the Reply-Message into an EAP-Notification and send it after the EAP-Success or EAP-Failure.
This is not compliant with the EAP specification (EAP-Notification needs to be sent prior to completion of an EAP authentication method). Sending it after EAP-Success or EAP-Failure would look like an attempt to initiate another authentication exchange.
It may be possible to send it before the EAP-Success/EAP-Failure message for some EAP methods, but chances are not all supplicants will like it, and most probably won't display anything.
EAP-Notification is not really supported in general and even the specification does not really require displaying anything from this message to the user.. There is also no way of authenticating this information, so this would not be ideal for authorization failures. - Jouni
On 21 Mar 2013, at 13:26, Jouni Malinen <jkmalinen@gmail.com> wrote:
On Mon, Mar 18, 2013 at 8:42 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
The old HP switches used to convert the Reply-Message into an EAP-Notification and send it after the EAP-Success or EAP-Failure.
This is not compliant with the EAP specification (EAP-Notification needs to be sent prior to completion of an EAP authentication method). Sending it after EAP-Success or EAP-Failure would look like an attempt to initiate another authentication exchange.
Their 802.1X implementation was pre RFC3579. In newer firmware releases this has been fixed.
It may be possible to send it before the EAP-Success/EAP-Failure message for some EAP methods, but chances are not all supplicants will like it, and most probably won't display anything.
EAP-Notification is not really supported in general and even the specification does not really require displaying anything from this message to the user.. There is also no way of authenticating this information, so this would not be ideal for authorization failures.
Agreed. But in the absence of a standards solution it might be interesting to experiment and see how supplicants respond to this. -Arran
Quoting Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 21 Mar 2013, at 13:26, Jouni Malinen <jkmalinen@gmail.com> wrote:
On Mon, Mar 18, 2013 at 8:42 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
The old HP switches used to convert the Reply-Message into an EAP-Notification and send it after the EAP-Success or EAP-Failure.
This is not compliant with the EAP specification (EAP-Notification needs to be sent prior to completion of an EAP authentication method). Sending it after EAP-Success or EAP-Failure would look like an attempt to initiate another authentication exchange.
Their 802.1X implementation was pre RFC3579. In newer firmware releases this has been fixed.
It may be possible to send it before the EAP-Success/EAP-Failure message for some EAP methods, but chances are not all supplicants will like it, and most probably won't display anything.
EAP-Notification is not really supported in general and even the specification does not really require displaying anything from this message to the user.. There is also no way of authenticating this information, so this would not be ideal for authorization failures.
Agreed. But in the absence of a standards solution it might be interesting to experiment and see how supplicants respond to this.
My RSA Windows EAP module sends EAP Notification messages under 4 different error circumstances. These are typically retry-able input problems. It was the default until the boffins that took over EAP for Windows 7 broke their code. XP and Vista worked fine, they took the request and responded with a blank response. No user visible message resulted. Win7 didn't respond at all, which caused the protocol to break. They patched it when I pointed out the problem. But I flipped off the default, don't know if/when that was released. There is a registry key that controls it. Dave.
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 21 Mar 2013, at 15:56, David Mitton <david@mitton.com> wrote:
Quoting Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 21 Mar 2013, at 13:26, Jouni Malinen <jkmalinen@gmail.com> wrote:
On Mon, Mar 18, 2013 at 8:42 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
The old HP switches used to convert the Reply-Message into an EAP-Notification and send it after the EAP-Success or EAP-Failure.
This is not compliant with the EAP specification (EAP-Notification needs to be sent prior to completion of an EAP authentication method). Sending it after EAP-Success or EAP-Failure would look like an attempt to initiate another authentication exchange.
Their 802.1X implementation was pre RFC3579. In newer firmware releases this has been fixed.
It may be possible to send it before the EAP-Success/EAP-Failure message for some EAP methods, but chances are not all supplicants will like it, and most probably won't display anything.
EAP-Notification is not really supported in general and even the specification does not really require displaying anything from this message to the user.. There is also no way of authenticating this information, so this would not be ideal for authorization failures.
Agreed. But in the absence of a standards solution it might be interesting to experiment and see how supplicants respond to this.
My RSA Windows EAP module sends EAP Notification messages under 4 different error circumstances. These are typically retry-able input problems. It was the default until the boffins that took over EAP for Windows 7 broke their code. XP and Vista worked fine, they took the request and responded with a blank response. No user visible message resulted. Win7 didn't respond at all, which caused the protocol to break. They patched it when I pointed out the problem. But I flipped off the default, don't know if/when that was released. There is a registry key that controls it.
Interesting. OSX does a similar thing, but it logs the notification, which can be very helpful if you're on the helpdesk and trying to diagnose issues. I wonder if Windows also does the silent logging. -Arran
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Danny Kurniawan -
David Mitton -
Jouni Malinen -
Olivier Beytrison