[Was: Problem with rlm_mschap from CVS] rlm_mschap: Unknown expansion string
Hello, I've checked out the exec.c fixes, but now there seem to be problems with variables passwed to ntlm_auth. Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 30 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: Told to do MS-CHAPv2 for myuser with NT-Password radius_xlat: '--username=myuser' radius_xlat: Running registered xlat function of module mschap for string 'Challenge:-00' rlm_mschap: Unknown expansion string "Challenge:-00" radius_xlat: '--challenge=' radius_xlat: Running registered xlat function of module mschap for string 'NT-Response:-00' rlm_mschap: Unknown expansion string "NT-Response:-00" radius_xlat: '--nt-response=' hex decode of failed! (only got 0 bytes) Exec-Program output: Exec-Program: returned: 1 rlm_mschap: External script failed. rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 30 modcall: leaving group MS-CHAP (returns reject) for request 30 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 30 modcall: leaving group authenticate (returns reject) for request 30 auth: Failed to validate the user. PEAP: Got tunneled reply RADIUS code 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Processing from tunneled session code 0x813a1d0 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Tunneled authentication was rejected. rlm_eap_peap: FAILURE Here is my ntlm_auth configuration: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username={Stripped-User-Name:-%{User-Name:-None}} --challenge={mschap:Challenge:-00} --nt-response={mschap:NT-Response:-00}" thanks -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: The keyboard isn't plugged in
Luca Corti wrote:
Here is my ntlm_auth configuration:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username={Stripped-User-Name:-%{User-Name:-None}} --challenge={mschap:Challenge:-00} --nt-response={mschap:NT-Response:-00}
IIRC, with the changes to the xlat stuff a while back for module xlats, if you want to keep the :- no-match stuff, you need to make it look like %{{mschap:challenge}:-00}. I think that's what we decided on. Anyway, I'm not using this in my config... my ntlm_auth line looks like: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name} --challenge=%{mschap:Challenge} --nt-response=%{mschap:NT-Response} --domain=%{mschap:NT-Domain}" --Mike
On Tue, 2005-11-15 at 09:38 -0600, Michael Griego wrote:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name} --challenge=%{mschap:Challenge} --nt-response=%{mschap:NT-Response} --domain=%{mschap:NT-Domain}"
Thanks a lot, this makes ntlm_auth work. Unfotunately now freeradius segfaults while sending Access-Accept: modcall: entering group authorize for request 8 modcall[authorize]: module "preprocess" returns ok for request 8 modcall[authorize]: module "mschap" returns noop for request 8 rlm_realm: Looking up realm "MYDOMAIN" for User-Name = "MYDOMAIN \myuser" rlm_realm: Found realm "MYDOMAIN" rlm_realm: Adding Stripped-User-Name = "myuser" rlm_realm: Proxying request from user myuser to realm MYDOMAIN rlm_realm: Adding Realm = "MYDOMAIN" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "ntdomain" returns noop for request 8 rlm_eap: EAP packet type response id 8 length 38 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 8 modcall: leaving group authorize (returns updated) for request 8 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 8 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 8 modcall: leaving group authenticate (returns ok) for request 8 Sending Access-Accept of id 8 to 172.16.1.250 port 1037 MS-MPPE-Recv-Key = 0x89fe613a15cbcbf6e9fa6d7b6f730db6c1a9c548c24c6ff3d67635d28caed390 Segmentation fault thanks Luca -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: need to wrap system in aluminum foil to fix problem
Luca Corti wrote:
On Tue, 2005-11-15 at 09:38 -0600, Michael Griego wrote:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name} --challenge=%{mschap:Challenge} --nt-response=%{mschap:NT-Response} --domain=%{mschap:NT-Domain}"
Thanks a lot, this makes ntlm_auth work. Unfotunately now freeradius segfaults while sending Access-Accept:
Please post the output of gdb, as explained here: http://freeradius.org/radiusd/doc/bugs -- Nicolas Baradakis
On Tue, 2005-11-15 at 19:25 +0100, Nicolas Baradakis wrote:
segfaults while sending Access-Accept: Please post the output of gdb, as explained here: http://freeradius.org/radiusd/doc/bugs
Ok, please forgive my newbieness on debugging. I've read the link you posted, issued ulimit -c unlimited and set allow_core_dumps = yes in radiusd.conf. Then started freeradius freeradius -X (also tried -x and init.d script) and reproduced the problem. I can't find the core file though... were is it supposed to be saved? thanks -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: The air conditioning water supply pipe ruptured over the machine room
On Tue, 15 Nov 2005, Luca Corti wrote:
freeradius -X (also tried -x and init.d script)
and reproduced the problem. I can't find the core file though... were is it supposed to be saved?
Luca, are you on a Linux/Unixish type system? If so, and if worst comes to worst, you may be able to find it with: find / -name '*core*' -print Some systems save the core files in a specific directory, some in the directory with the binary, some in the directory you started the program in, and some in the program's current working directory. Note that this may find an awful lot of files with the word "core" in them also, so you may want to pipe it through "less" or "more": find / -name '*core*' -print | less If you're running Windows, I don't know how it does core dumps or even if it does. :-) There is (or was) also an option in radiusd.conf that says "allow_core_dumps = no". You may need to set this to "yes," but I'm not sure that applies to debug mode. Kristina
On Tue, 2005-11-15 at 11:54 -0800, Kristina Pfaff-Harris wrote:
Luca, are you on a Linux/Unixish type system? If so, and if worst comes to
Yes, I'm on Debian GNU/Linux.
worst, you may be able to find it with:
find / -name '*core*' -print
Already tried to do a find, it lists quite a lot of files, but they all seem to be system files (/proc stuff, kernel modules, xml dtds, etc.).
If you're running Windows, I don't know how it does core dumps or even if it does. :-)
That's not the case.
There is (or was) also an option in radiusd.conf that says "allow_core_dumps = no". You may need to set this to "yes," but I'm not sure that applies to debug mode.
As I said I set allow_core_dumps to yes and tried running freeradius both in debugging and non-debugging mode. thanks Luca -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: Too much radiation coming from the soil.
On Wed, 16 Nov 2005, Luca Corti wrote:
There is (or was) also an option in radiusd.conf that says "allow_core_dumps = no". You may need to set this to "yes," but I'm not sure that applies to debug mode.
As I said I set allow_core_dumps to yes and tried running freeradius both in debugging and non-debugging mode.
My apologies -- I must have missed that. Erm. Maybe Alan knows? I know that in the lonnnng past, "make install" would also strip debugging symbols so the core dumps didn't do much good, but I don't know why it wouldn't core dump to a findable file at all. Sorry. :-( Kristina
participants (4)
-
Kristina Pfaff-Harris -
Luca Corti -
Michael Griego -
Nicolas Baradakis