Can RADIUS indicate a standardised reason for access rejection?
Hi there, Imagine you use EAP-TTLS + PAP for 802.1X authentication. You have client which is able to authenticate. One day password changes or expires (server-side). Client attempts to authenticate using the old password. RADIUS server will reply with Access-Reject. Can RADIUS server add some standardised message/attribute to the message indicating the reason for the rejection? E.g. "reason: password expired", e.g. "reason: wrong password", etc. The key is the "standardised". I know I can provide any reply message but here I would need to reply with something the client and/or NAS expect and can react to accordingly. Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. macOS displays very cryptic message about a connection problem (no prompt to enter the password). Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials). Best, Michal Moravec
On 18.08.22 10:14, Michal Moravec wrote:
Hi there,
Imagine you use EAP-TTLS + PAP for 802.1X authentication. You have client which is able to authenticate. One day password changes or expires (server-side). Client attempts to authenticate using the old password. RADIUS server will reply with Access-Reject.
Can RADIUS server add some standardised message/attribute to the message indicating the reason for the rejection? E.g. "reason: password expired", e.g. "reason: wrong password", etc. The key is the "standardised". I know I can provide any reply message but here I would need to reply with something the client and/or NAS expect and can react to accordingly.
Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. macOS displays very cryptic message about a connection problem (no prompt to enter the password). Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials).
Best, Michal Moravec
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RADIUS can set the Reply-Message Attribute. Se you could set it to "Your password expired. Please use the new one". But the question is, if the MAC client will display this Reply-Message to the user. Test it. Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
On Aug 18, 2022, at 4:14 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
Imagine you use EAP-TTLS + PAP for 802.1X authentication. You have client which is able to authenticate. One day password changes or expires (server-side). Client attempts to authenticate using the old password. RADIUS server will reply with Access-Reject.
Can RADIUS server add some standardised message/attribute to the message indicating the reason for the rejection?
In theory, yes. In practice, no. RADIUS provides for Reply-Message, which is sent to the NAS, and then should be sent over a PPP link to the end user. This doesn't work with EAP and Access Points. EAP provides for EAP Notification packets, which are sent from the Access Point to the supplicant (end user system). Unfortunately, most supplicants treat this packet as a failure. Worse, they never show anything to the end user.
E.g. "reason: password expired", e.g. "reason: wrong password", etc. The key is the "standardised". I know I can provide any reply message but here I would need to reply with something the client and/or NAS expect and can react to accordingly.
The client has to show the message to the user. And the clients don't do this.
Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. macOS displays very cryptic message about a connection problem (no prompt to enter the password). Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials).
TLS has various alerts (certificate expired, etc). So far as I can tell, the clients don't show those to the user either. It's like they all have a policy against showing any useful information to the user. Alan DeKok.
Thank you for very insightful responses. One other thing I have noticed is that after the (Cisco Meraki) Access Point receives Access-Reject message from RADIUS it will disassociate the supplicant sending reason code 8 "Disassociated because sending STA is leaving or has left Basic Service Set (BSS)." https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-... <https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-5/help/Apx_ReasonCodes2.html> There is a defined reason code (23) which seems to be more appropriate for the situation: "IEEE 802.1X authentication failed." Do you know whether this reason code should be used? If so what is the common practice? Do vendors do it? However even with answer to that I don't know if this would help in my case since I can not inspect Apple Wi-Fi (Airport) code because it is closed-source (unlike kernel and 802.1X client). MM
On 18. 8. 2022, at 14:52, Alan DeKok <aland@deployingradius.com> wrote:
On Aug 18, 2022, at 4:14 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
Imagine you use EAP-TTLS + PAP for 802.1X authentication. You have client which is able to authenticate. One day password changes or expires (server-side). Client attempts to authenticate using the old password. RADIUS server will reply with Access-Reject.
Can RADIUS server add some standardised message/attribute to the message indicating the reason for the rejection?
In theory, yes. In practice, no.
RADIUS provides for Reply-Message, which is sent to the NAS, and then should be sent over a PPP link to the end user. This doesn't work with EAP and Access Points.
EAP provides for EAP Notification packets, which are sent from the Access Point to the supplicant (end user system). Unfortunately, most supplicants treat this packet as a failure. Worse, they never show anything to the end user.
E.g. "reason: password expired", e.g. "reason: wrong password", etc. The key is the "standardised". I know I can provide any reply message but here I would need to reply with something the client and/or NAS expect and can react to accordingly.
The client has to show the message to the user. And the clients don't do this.
Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. macOS displays very cryptic message about a connection problem (no prompt to enter the password). Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials).
TLS has various alerts (certificate expired, etc). So far as I can tell, the clients don't show those to the user either.
It's like they all have a policy against showing any useful information to the user.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 18, 2022, at 9:10 AM, Michal Moravec <michal.moravec@macadmin.cz> wrote:
Thank you for very insightful responses.
One other thing I have noticed is that after the (Cisco Meraki) Access Point receives Access-Reject message from RADIUS it will disassociate the supplicant sending reason code 8 "Disassociated because sending STA is leaving or has left Basic Service Set (BSS)." https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-... <https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-5/help/Apx_ReasonCodes2.html> There is a defined reason code (23) which seems to be more appropriate for the situation: "IEEE 802.1X authentication failed."
There is no way in RADIUS to tell the AP to send that message.
Do you know whether this reason code should be used?
It should be used.
If so what is the common practice? Do vendors do it?
I've never looked at the packet traces to tell. I suspect it is sent, but it doesn't matter. The supplicant already knows that the authentication failed, because it gets an EAP failure packet. What is missing is the ability to send a *reason* for the failure.
However even with answer to that I don't know if this would help in my case since I can not inspect Apple Wi-Fi (Airport) code because it is closed-source (unlike kernel and 802.1X client).
It runs NetBSD, but it's still closed. Alan DeKok.
Hi,
Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. macOS displays very cryptic message about a connection problem (no prompt to enter the password). Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials).
In a similar situation we took a different approach. On authentication failure we override the response and send them into a dedicated vrf with a walled garden web page that says something like Your session was not authenticated properly. Please check your login credentials and try again. Works well for most users and cut down on tickets Brian
participants (4)
-
Alan DeKok -
Brian Turnbow -
Michael Schwartzkopff -
Michal Moravec