Want to silently discard the request if authentication module as web service client connecting to the web service server is down.
Hi In FreeRadius 2.1.11, we have created a module name "ws" which authenticate and authorize the user request through the web-service call, exposed as a WSDL. In the successful scenario when both Radius server and web service are up, we are able to authenticate and authorize the user request and in the failure scenario when both Radius server and web service are up, but the user credential are not correct, radius server reject the request as expected. But If the exposed web-service is down, Radius server simply reject the authentication request with the response message as "Access_Rejected". We want Radius server instead of rejecting, simply discard the authentication request which will allow the RADIUS *client* to failover to another RADIUS server. So while going through the FreeRadius configuration i came across the section in sites-avaliable/default file under "post-auth" section which state that "Access-Reject packets are sent through the REJECT sub-section of the post-auth section." and is as follow: Post-Auth-Type REJECT { # log failed authentications in SQL, too. #sql attr_filter.access_reject } If you think this is the right approach, could you please provide me the sample code using which if i could check for the rlm status code and could silently discard the responses other than the "RLM_MODULE_OK" and "RLM_MODULE_REJECTED. Thanks & Regards, --Ankur
Ankur G <ankur.g@globallogic.com> wrote:
But If the exposed web-service is down, Radius server simply reject the authentication request with the response message as "Access_Rejected".
We want Radius server instead of rejecting, simply discard the authentication request which will allow the RADIUS *client* to failover to another RADIUS server.
...surely the other RADIUS server the client has listed will also be unable to process the request as the web service is down? If you have multiple web-service instances about, then your perl/python/exec code should failover to using other instances. I find it hard how this situation would help you in practise (W -> web, R -> RADIUS server, C -> RADIUS client) as surely if R1 is unable to talk to W, having C failover to R2 is not going to help? /--- R1 ---\ W --- --- C \--- R2 ---/ If you have W1 and W2, then R1 and R2 should be able to talk to both.
So while going through the FreeRadius configuration i came across the section in sites-avaliable/default file under "post-auth" section which state that "Access-Reject packets are sent through the REJECT sub-section of the post-auth section." and is as follow:
Post-Auth-Type REJECT { # log failed authentications in SQL, too. #sql attr_filter.access_reject }
If you think this is the right approach, could you please provide me the sample code using which if i could check for the rlm status code and could silently discard the responses other than the "RLM_MODULE_OK" and "RLM_MODULE_REJECTED.
http://wiki.freeradius.org/Modules2#Module+Return+Codes RLM_MODULE_FAIL looks like a better option to use, although it will not give you what you want; but it would enable you to use unlang to perform other tasks. Cheers -- Alexander Clouter .sigmonster says: You fill a much-needed gap.
Alexander, We have a little different scenario. We have two different instances of web server connecting to two different Radius server such that if one of the radius server not able to connect the webserver, radius client can fail over to another radius server which has a different web-server connecting. Find below is the scenario: /--W1--\ -- /--- R1 ---\ --- C /--W2--\ -- /--- R2 ---\ --Ankur On Tue, Aug 9, 2011 at 11:54 PM, Alexander Clouter <alex@digriz.org.uk>wrote:
Ankur G <ankur.g@globallogic.com> wrote:
But If the exposed web-service is down, Radius server simply reject the authentication request with the response message as "Access_Rejected".
We want Radius server instead of rejecting, simply discard the authentication request which will allow the RADIUS *client* to failover
to
another RADIUS server.
...surely the other RADIUS server the client has listed will also be unable to process the request as the web service is down?
If you have multiple web-service instances about, then your perl/python/exec code should failover to using other instances.
I find it hard how this situation would help you in practise (W -> web, R -> RADIUS server, C -> RADIUS client) as surely if R1 is unable to talk to W, having C failover to R2 is not going to help?
/--- R1 ---\ W --- --- C \--- R2 ---/
If you have W1 and W2, then R1 and R2 should be able to talk to both.
So while going through the FreeRadius configuration i came across the section in sites-avaliable/default file under "post-auth" section which state that "Access-Reject packets are sent through the REJECT sub-section of the post-auth section." and is as follow:
Post-Auth-Type REJECT { # log failed authentications in SQL, too. #sql attr_filter.access_reject }
If you think this is the right approach, could you please provide me the sample code using which if i could check for the rlm status code and could silently discard the responses other than the "RLM_MODULE_OK" and "RLM_MODULE_REJECTED.
http://wiki.freeradius.org/Modules2#Module+Return+Codes
RLM_MODULE_FAIL looks like a better option to use, although it will not give you what you want; but it would enable you to use unlang to perform other tasks.
Cheers
-- Alexander Clouter .sigmonster says: You fill a much-needed gap.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Thanks & Regards, Ankur Gupta | Consultant-Engineering | GlobalLogic Inc. *Leaders in Software R&D Services* ARGENTINA | CHINA | INDIA | ISRAEL | UKRAINE | UK | USA Office: +91-120-406-2000 x <2486> | Mobile +91-981-061-4704 *Fax: +91-120-258-5721 | Blog: blogs.globallogic.com* www.globallogic.com Follow us on Twitter <http://twitter.com/GlobalLogicInc>! *Disclaimer: http://www.globallogic.com/email_disclaimer.txt*
Ankur G <ankur.g@globallogic.com> wrote:
We have a little different scenario. We have two different instances of web server connecting to two different Radius server such that if one of the radius server not able to connect the webserver, radius client can fail over to another radius server which has a different web-server connecting. Find below is the scenario:
/--W1--\ -- /--- R1 ---\ --- C /--W2--\ -- /--- R2 ---\
Why can't R1 talk to W1 *and* W2? Your module should be able to try using both surely (if W1 fails, it should try W2)? I suspect it would be a strange network failure if W1 and W2 are unreachable to R1 but R2 could still speak to W2 (misconfiguration rather than node/router failure)? Well, you should still use FAIL in your module rather than REJECT if something internal to the module has failed. Combine this with what Alan already has pointed you to, do_not_respond in policy.conf, and you should be able to get to where you want to be. Cheers -- Alexander Clouter .sigmonster says: If you sow your wild oats, hope for a crop failure.
Ankur G wrote:
We want Radius server instead of rejecting, simply discard the authentication request which will allow the RADIUS *client* to failover to another RADIUS server.
Read raddb/policy.conf. Look for "do not respond" Alan DeKok.
participants (3)
-
Alan DeKok -
Alexander Clouter -
Ankur G