Dear Stefan, thank you for your answer. "When their talk ends nowhere all that can be said is that the two parties disagree about what the password is. " I understand that it is like that by design: EAP-PWD RFC says in 2.8.5.3 EAP-pwd-Confirm-Exchange: "If the value of Confim_S i incorrect, the peer MUST terminate the exchange" ... I think this could be the point where it happens (I'm not too deep into EAP-PWD). I understand, that the freeradius-module is written like in the RFC defined. RADIUS RFC says: If any value of the received Attributes is not acceptable, then the RADIUS Server MUST transmit a packet with the Code field set to 3 (Access-Reject). I think, that does not match here, because it is not the server who does not accept the packet ,but: "Upon receipt of an Access-Request from a valid client, an appropriate reply MUST be transmitted." So, the question is for me: Is this a "valid" client or not? MUST there be a reply? Wouldn't it be an idea, the EAP-PWD peer sends back an explizit "I disagree with you, let us stop talking" (some kind of NAK)? Just asking :-) Ciao Anja
Stefan Winter <stefan.winter@restena.lu> 11.09.2018 13:51 >>> Hello,
Is there a way to determine that a user tried to log in with a "wrong password" with eap-pwd? Setup is as recommended by comments in config with an inner-tunnel.
EAP-PWD against edir with a correct password works fine and it produces a log line on Access-Accept in the radius-Logfile.
But EAP-PWD with the user using a wrong password, does nothing. In debug it just looks like an unfinished eap-request with eap returning handled instead of ok for the last packet.
Problem is, that we cannot see "normal" entry in radius.log and trigger some other actions on a reject.
Two guys who know nothing about each other talk about a password they hold close to their chest, not showing to the other side. When their talk about the passwords shows that they actually have the same password in front of them then both are happy, knowing that the respective other side is genuine. When their talk ends nowhere all that can be said is that the two parties disagree about what the password is. There is then no "wrong" and "right" password. They are just different. And so, both ends walk away. I.e. the user cannot know if his password is wrong, or if he is maybe connected to a rogue server which doesn't actually know the password and is trying to impersonate the server (failing miserably). The server, which at some point sends the Commit message based on what it thinks is the password, never gets a reply because the other end went away. But it can't know whether the other end went away because the password talk went sideways, or if the other end simply closed the laptop's lid and never received and acted upon the message. So, what should the server log? It can't be sure it was about a bad password. All it knows is that it sent something but noone replied. Should it maybe log that, instead of just doing nothing? How long should it wait before doing so? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66