How to allow wrong passwords in Peap-Mschapv2?
I'm trying to deploy freeadius 3.0.21, and having a problem. I need to support peap-machapv2 and peap-gtc authentication protocols. My boss is very old and often enters wrong passwords. I need to temporarily bypass password verification for him. Regardless of whether the password is correct or not, his computer will eventually complete peap-machapv2 authentication. I tried many methods, such as configuring his MAC address directly Auth-Type := Accept in authorize, but it didn't seem to work. thank you for your time -- Neil Shi
You can't, because of the encryption. If password is wrong then the encryption is wrong too. It is only possible with PAP as far as i know. Igor On 17.1.2025. 10:03, daoxuan shi wrote:
I'm trying to deploy freeadius 3.0.21, and having a problem. I need to support peap-machapv2 and peap-gtc authentication protocols. My boss is very old and often enters wrong passwords. I need to temporarily bypass password verification for him. Regardless of whether the password is correct or not, his computer will eventually complete peap-machapv2 authentication. I tried many methods, such as configuring his MAC address directly Auth-Type := Accept in authorize, but it didn't seem to work.
thank you for your time
On Jan 17, 2025, at 4:03 AM, daoxuan shi <shidaoxuan@gmail.com> wrote:
I'm trying to deploy freeadius 3.0.21, and having a problem. I need to support peap-machapv2 and peap-gtc authentication protocols. My boss is very old and often enters wrong passwords. I need to temporarily bypass password verification for him. Regardless of whether the password is correct or not, his computer will eventually complete peap-machapv2 authentication. I tried many methods, such as configuring his MAC address directly Auth-Type := Accept in authorize, but it didn't seem to work.
It's impossible. And why is someone re-entering passwords? The system should cache the password, and just re-use the cached passwords. So he's not "re-entering" the password wrong. Something or someone is actively deleting the cached password, which forces him to re-enter it. Why is the cached password being deleted from his system? Is someone deleting the WiFi configuration? If so, why? Alan DeKok.
I have found the method to achieve this goal, and I will provide a few examples below: 1. **For PEAP-MSCHAPv2 authentication**, you need to add the following configuration in the inner `authorize` section: ```plaintext authorize { ...... -ldap update { &control:SMB-Account-CTRL-TEXT := '[N]' &reply:MS-CHAP2-Success = 'password-free' } } ``` 2. **For PEAP-GTC authentication**, you need to add the following configuration in the inner `authorize` section: ```plaintext authorize { ...... -ldap if (EAP-Type == GTC) { update { Auth-Type := Accept } } ...... } ``` These configurations are tailored to the respective authentication methods, ensuring proper handling of the authentication process. Let me know if you need further clarification or additional translations! Alan DeKok <aland@deployingradius.com> 于2025年1月17日周五 21:49写道：
On Jan 17, 2025, at 4:03 AM, daoxuan shi <shidaoxuan@gmail.com> wrote:
I'm trying to deploy freeadius 3.0.21, and having a problem. I need to support peap-machapv2 and peap-gtc authentication protocols. My boss is very old and often enters wrong passwords. I need to
temporarily
bypass password verification for him. Regardless of whether the password is correct or not, his computer will eventually complete peap-machapv2 authentication. I tried many methods, such as configuring his MAC address directly Auth-Type := Accept in authorize, but it didn't seem to work.
It's impossible.
And why is someone re-entering passwords? The system should cache the password, and just re-use the cached passwords.
So he's not "re-entering" the password wrong. Something or someone is actively deleting the cached password, which forces him to re-enter it.
Why is the cached password being deleted from his system? Is someone deleting the WiFi configuration? If so, why?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- —— 敬启 史道轩
On Jan 23, 2025, at 12:02 AM, daoxuan shi <shidaoxuan@gmail.com> wrote:
I have found the method to achieve this goal, and I will provide a few examples below:
That surprises me. RFC 2759 is very clear that the Success packet has to be checked by the client; https://datatracker.ietf.org/doc/html/rfc2759#section-5 The authenticating peer MUST verify the authenticator response when a Success packet is received. The method for verifying the authenticator is described in section 8.8, below. If the authenticator response is either missing or incorrect, the peer MUST end the session. I'll have to try this out. If it works, we'll update the examples and documentation. Alan DeKok.
participants (3)
-
Alan DeKok -
daoxuan shi -
Igor Smitran