Hi, I would like to know whether or not the following configuration *can* work, and if so, what I need to know to get it to work. I have gotten peap/mschapv2 to work from the standard users file, so that is all working. What I want to do know is pass all the logic to a perl script, however eveytime I do that I get the following error +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/inner-tunnel +group authenticate { [eap] Request found, released from the list [eap] EAP/mschapv2 [eap] processing type mschapv2 [mschapv2] # Executing group from file /etc/raddb/sites-enabled/inner-tunnel [mschapv2] +group MS-CHAP { rlm_perl: PERL USERNAME ryan@test.com rlm_perl: PERL USERNAME test rlm_perl: Added pair Cleartext-Password = test rlm_perl: Added pair State = 0x6a981b696a90018e48312d75606ef989 rlm_perl: Added pair MS-CHAP-User-Name = ryan@test.com rlm_perl: Added pair MS-CHAP-Challenge = 0x263fa419e8c59a51b8f7bda3b0dbd476 rlm_perl: Added pair FreeRADIUS-Proxied-To = 127.0.0.1 rlm_perl: Added pair User-Name = ryan@test.com rlm_perl: Added pair EAP-Message = 0x020800541a0208004f3197d01dac5bed333c13a1b2a4139575a600000000000000002509ca1d6892684e813e061da39c12bcc360d638c9bb2504007279616e40636f6e6e656374656473706163652e636f2e7a61 rlm_perl: Added pair MS-CHAP2-Response = 0x087997d01dac5bed333c13a1b2a4139575a600000000000000002509ca1d6892684e813e061da39c12bcc360d638c9bb2504 rlm_perl: Added pair EAP-Type = MS-CHAP-V2 rlm_perl: Added pair Cleartext-Password = test rlm_perl: Added pair h323-credit-amount = 100 rlm_perl: Added pair Auth-Type = EAP rlm_perl: Added pair Proxy-To-Realm = LOCAL ++[dot1x] = updated [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] Creating challenge hash with username: ryan@test.com [mschap] Client is using MS-CHAPv2 for ryan@test.com, we need NT-Password *[mschap] FAILED: No NT/LM-Password. Cannot perform authentication.* *[mschap] FAILED: MS-CHAP2-Response is incorrect* some more # Executing group from file /etc/raddb/sites-enabled/8021x +group authenticate { [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS [peap] eaptls_verify returned 7 [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Peap state send tlv failure [peap] Received EAP-TLV response. [peap] The users session was previously rejected: returning reject (again.) [peap] *** This means you need to read the PREVIOUS messages in the debug output [peap] *** to find out the reason why the user was rejected. [peap] *** Look for "reject" or "fail". Those earlier messages will tell you. [peap] *** what went wrong, and how to fix the problem. [eap] Handler failed in EAP/peap [eap] Failed in EAP select ++[eap] = invalid +} # group authenticate = invalid Failed to authenticate the user. So. How can I fix this? Here is my inner-tunnel authorize section authorize { chap *dot1x* mschap } and the dot1x module calls a script called dot1x.pl The script is *so* basic right now, all I want it to do is to update the Cleartext-password attribute so that the user can authenticate. Currently it looks like this sub authorize { # For debugging purposes only # &log_request_attributes; #debugging &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'User-Name'}); &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'Cleartext-Password'}); #trying to update the cleartext-password to the one the user enters. $RAD_REQUEST{'Cleartext-Password'} = "test"; $RAD_REPLY{'Cleartext-Password'} = 'test'; return RLM_MODULE_UPDATED; } any advice would be great
On 08-02-16 13:16, Ryan De Kock wrote:
#debugging &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'User-Name'}); &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'Cleartext-Password'});
That second line is pretty much useless, not only has this nothing to do with a username, there won't be a Cleartext-Password in the request.
#trying to update the cleartext-password to the one the user enters. $RAD_REQUEST{'Cleartext-Password'} = "test"; $RAD_REPLY{'Cleartext-Password'} = 'test';
You have to write it to the control list instead of request/reply. Try the following: $RAD_CHECK{'Cleartext-Password'} = 'test'; (The actual name of the perl hash required here varies among versions, this is the hash that should work in v3.0.11) -- Herwin Weststrate
Thanks. I was just grasping at straws, hoping something would happen to give me a clue. I notice that the rlm_perl docs state that its read only, I'm not near an Access Point to actually test at the moment # %RAD_CHECK Read-only Check items # %RAD_REQUEST Read-only Attributes from the request # %RAD_REPLY Read-write Attributes for the reply On 8 February 2016 at 14:39, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
On 08-02-16 13:16, Ryan De Kock wrote:
#debugging &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'User-Name'}); &radiusd::radlog(1,"PERL USERNAME " . $RAD_REQUEST{'Cleartext-Password'});
That second line is pretty much useless, not only has this nothing to do with a username, there won't be a Cleartext-Password in the request.
#trying to update the cleartext-password to the one the user
enters.
$RAD_REQUEST{'Cleartext-Password'} = "test"; $RAD_REPLY{'Cleartext-Password'} = 'test';
You have to write it to the control list instead of request/reply. Try the following:
$RAD_CHECK{'Cleartext-Password'} = 'test';
(The actual name of the perl hash required here varies among versions, this is the hash that should work in v3.0.11)
-- Herwin Weststrate - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 8, 2016, at 9:06 AM, Ryan De Kock <ryandekock1988@gmail.com> wrote:
I was just grasping at straws, hoping something would happen to give me a clue.
I notice that the rlm_perl docs state that its read only, I'm not near an Access Point to actually test at the moment
You can test with eapol_test. Full instructions are on http://deployingradius.com Alan DeKok.
I was just grasping at straws, hoping something would happen to give me a clue.
I notice that the rlm_perl docs state that its read only, I'm not near an Access Point to actually test at the moment
# %RAD_CHECK Read-only Check items # %RAD_REQUEST Read-only Attributes from the request # %RAD_REPLY Read-write Attributes for the reply
That's incorrect. The RAD_CHECK hash is read/write. You have another hash, RAD_CONFIG, which also maps to control items but is read only. (I'm not sure what use it is, probably for backward compatibility.) Anyway, you can modify RAD_CHECK. And RAD_REQUEST is read/write too. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 08-02-16 15:36, Chaigneau, Nicolas wrote:
That's incorrect. The RAD_CHECK hash is read/write. You have another hash, RAD_CONFIG, which also maps to control items but is read only. (I'm not sure what use it is, probably for backward compatibility.)
It has indeed been kept in v3.0.x for backwards compatibility. Somehow botch RAD_CHECK and RAD_CONFIG had ended up in rlm_perl some day. Since rlm_perl works with replacing the complete list in freeradius with values read from the hash, and both these lists were used, the values of RAD_CONFIG were overwritten by the values of RAD_CHECK, making the first effectively read-only. Freeradius v3.1.x is a bit cleaner here, but v3.0.x can't simply be updated because older scripts may break. -- Herwin Weststrate
Yip. That was it, a simple change to RAD_CHECK sorted out my issue On 8 February 2016 at 17:02, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
On 08-02-16 15:36, Chaigneau, Nicolas wrote:
That's incorrect. The RAD_CHECK hash is read/write. You have another hash, RAD_CONFIG, which also maps to control items but is read only. (I'm not sure what use it is, probably for backward compatibility.)
It has indeed been kept in v3.0.x for backwards compatibility. Somehow botch RAD_CHECK and RAD_CONFIG had ended up in rlm_perl some day. Since rlm_perl works with replacing the complete list in freeradius with values read from the hash, and both these lists were used, the values of RAD_CONFIG were overwritten by the values of RAD_CHECK, making the first effectively read-only. Freeradius v3.1.x is a bit cleaner here, but v3.0.x can't simply be updated because older scripts may break.
-- Herwin Weststrate
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 08-02-16 15:06, Ryan De Kock wrote:
I notice that the rlm_perl docs state that its read only
# %RAD_CHECK Read-only Check items # %RAD_REQUEST Read-only Attributes from the request # %RAD_REPLY Read-write Attributes for the reply
Either your version of FreeRADIUS is outdated, the docs you're using are outdated or both, it's impossible to tell from this information. -- Herwin Weststrate
participants (4)
-
Alan DeKok -
Chaigneau, Nicolas -
Herwin Weststrate -
Ryan De Kock