Re: Access-Reject in a php script
Hi, Have you find out any solutions to that problem? I'm waiting for an answer before modifying the source code... May be, there is a bug and the official source code should be modified as Patric did. Cheers! Khalid :) Hi all,
Thanks again! I've tried to put return(2) and it does not work because my client receives an Access-Accept. If I let exit(2), the server does not send anything so the client fall in time out. The user will not have access but he will make many attempts as long as he does not receive an Access-Reject packet. Furthermore, he needs to know what is going on... BTW, I'm using the "NTRadPing Test Utility" client.
hereunder is the output debug: Module: Instantiated realm (suffix) exec: wait = yes exec: program = "/home/authentication.php" exec: input_pairs = "request" exec: output_pairs = "reply" exec: packet_type = "Access-Request" Module: Instantiated exec (myauth) Module: Instantiated files (files) exec: wait = yes exec: program = "/home/accounting.php" exec: input_pairs = "request" exec: output_pairs = "reply" exec: packet_type = "Accounting-Request" Module: Instantiated exec (myacct)
rad_recv: Access-Request packet from host x.x.x.x:2658, id=49, length=58 User-Name = "xxx" User-Password = "xxx" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: Looking up realm "xxx" for User-Name = "xxx" rlm_realm: No such realm "xxxx" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 Exec-Program output: Exec-Program: returned: 2 rlm_exec (myauth): External script failed modcall[authorize]: module "myauth" returns fail for request 0 modcall: leaving group authorize (returns fail) for request 0 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host xxxxx, id=49, length=58 Discarding duplicate request from client xxxx - ID: 49 --- Walking the entire request list --- Waking up in 2 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 49 with timestamp 4721d900 Nothing to do. Sleeping until we see a request.
Thank you very much anyway!
Patric wrote:
Something just occurred to me that I dont think I tried before. What happens if instead of doing an
exit(2);
you do a
return(2);
This way your script will still exit clean, so freeradius wont pick it up as a script failure, but hopefully will still get the result?
No. If the script succeeds, the output is either a text message, or RADIUS attributes that go into an Access-Accept.
If the script fails, the server sends an Access-Reject.
Stop playing games with PHP and post the output of "radiusd -X". I'll bet money that the solution is right there in the debug output.
Alan DeKok.
manIP wrote:
Have you find out any solutions to that problem?
There are whole hours when I don't read this list.
I'm waiting for an answer before modifying the source code... May be, there is a bug and the official source code should be modified as Patric did.
Yes, the debug output helped. It looks like it's an issue with src/main/exec.c. The code calling module_authorize() should treat FAIL the same as REJECT. Alan DeKok.
Alan DeKok wrote:
Yes, the debug output helped. It looks like it's an issue with src/main/exec.c. The code calling module_authorize() should treat FAIL the same as REJECT.
Is that src/main/exec.c or src/main/auth.c? If I look at src/main/auth.c I see the following : int rad_authenticate(REQUEST *request) { ... /* Get the user's authorization information from the database */ autz_redo: result = module_authorize(autz_type, request); switch (result) { case RLM_MODULE_NOOP: case RLM_MODULE_NOTFOUND: case RLM_MODULE_OK: case RLM_MODULE_UPDATED: break; case RLM_MODULE_FAIL: case RLM_MODULE_HANDLED: return result; case RLM_MODULE_INVALID: case RLM_MODULE_REJECT: case RLM_MODULE_USERLOCK: default: ... Is this the code you are referring to? Should RLM_MODULE_FAIL go in with the last few that drop into the default case? So this would fix it : result = module_authorize(autz_type, request); switch (result) { case RLM_MODULE_NOOP: case RLM_MODULE_NOTFOUND: case RLM_MODULE_OK: case RLM_MODULE_UPDATED: break; /*case RLM_MODULE_FAIL:*/ case RLM_MODULE_HANDLED: return result; case RLM_MODULE_FAIL: case RLM_MODULE_INVALID: case RLM_MODULE_REJECT: case RLM_MODULE_USERLOCK: default: Makes sense, because the default case returns a reject... Alan you are a genius! Is this even considered a bug? Can we expect this to be changed in the future? Thanks a stack for all the time Alan! -- Q: I want to be a sysadmin. What should I do? A: Seek professional help. ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com/tag/1
Patric wrote:
Alan DeKok wrote: Is that src/main/exec.c or src/main/auth.c?
Sorry, src/main/auth.c
If I look at src/main/auth.c I see the following :
int rad_authenticate(REQUEST *request) { ... /* Get the user's authorization information from the database */ autz_redo: result = module_authorize(autz_type, request); switch (result) { case RLM_MODULE_NOOP: case RLM_MODULE_NOTFOUND: case RLM_MODULE_OK: case RLM_MODULE_UPDATED: break; case RLM_MODULE_FAIL:
Delete this line.
case RLM_MODULE_HANDLED: return result; case RLM_MODULE_INVALID:
Put a copy of that line here.
case RLM_MODULE_REJECT: case RLM_MODULE_USERLOCK: default: ...
Is this the code you are referring to? Should RLM_MODULE_FAIL go in with the last few that drop into the default case?
Yes.
Makes sense, because the default case returns a reject... Alan you are a genius!
Sometimes. If you look at who wrote that code in the first place...
Is this even considered a bug? Can we expect this to be changed in the future?
Yes.
Thanks a stack for all the time Alan!
You're welcome. Alan DeKok.
Alan DeKok wrote:
Is this even considered a bug? Can we expect this to be changed in the future?
Yes.
Not sure if you looked at the changes I originally made to rlm_exec.c but if you did, I was curious as to whether those changes contradicted the FreeRadius RFC's at all? I dont *think* so, but you never know :] -- Q: I want to be a sysadmin. What should I do? A: Seek professional help. ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com/tag/1
participants (3)
-
Alan DeKok -
manIP -
Patric