[RADIATOR] Conditionally deleting Reply-Message attribute inAccess-Reject

Hugh Irvine hugh at open.com.au
Wed Aug 12 18:03:22 CDT 2009


Hello Adnan -

The ReplyHook is called in the proxy RADIUS packet processing module  
in "Radius/AuthRADIUS.pm".

The PostProcessingHook is called in "Radius/Handler.pm" after "Radius/ 
AuthRADIUS.pm" completes.

The processing flow is:

"radiusd" - receives and unpacks the packet, calls "Radius/Client.pm"

"Radius/Client.pm" - does per-Client processing, calls "Radius/ 
Handler.pm"

"Radius/Handler.pm" - does per-Handler processing, calls "Radius/ 
AuthRADIUS.pm" (in the proxy case)

"Radius/AuthRADIUS.pm" - forwards the request to the proxy target,  
saves state and returns "Ignore"

"radiusd" - receives and unpacks the next packet, .....

......

when the reply from the proxy target is received

"Radius/AuthRADIUS.pm" - restores previously saved state for this  
request, calls ReplyHook, finishes processing, returns to "Radius/ 
Handler.pm"

  "Radius/Handler.pm" - finishes processing, calls PostProcessingHook,  
returns to "Radius/Client.pm"

"Radius/Client.pm" - sends the response back to the Client

.....

For details I suggest you read in order, "radiusd", "Radius/ 
Client.pm", "Radius/Handler.pm", "Radius/AuthFILE.pm", "Radius/ 
AuthGeneric.pm" and "Radius/AuthRADIUS.pm".

regards

Hugh


On 12 Aug 2009, at 23:02, Adnan Smajlovic wrote:

> I moved the contents of the ReplyHook into a PostProcessingHook and  
> got the desired effect.
>
> Looking at the execution sequence as described in the manual:
>
> 21. (if the request was proxied to another RADIUS server...) Reply  
> received from proxy server
> 22. ReplyHook called
> 23. PostProcessingHook called
> 24. Reply sent to NAS
>
> Forgive me if what follows is in the manual (or a stupid question),  
> the local Reply-Message is added between steps 22 and 23.  Could  
> someone please elaborate on the process flow here?
>
> Regards,
>
> --
> Adnan
>
> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au 
> ] On Behalf Of Adnan Smajlovic
> Sent: 11 August 2009 16:40
> To: radiator at open.com.au
> Subject: [RADIATOR] Conditionally deleting Reply-Message attribute  
> inAccess-Reject
>
> Hi,
>
> We are currently trying to find a way to remove the Reply-Message  
> from an Access-Reject if that message is equivalent to a particular  
> string.  This is using Radiator 4.4.
>
> A client sends a request to a RADIUS proxy, which adds an attribute  
> before sending it off for authentication by our core RADIUS server.   
> We’re happy for the Reply-Message to be sent back if it is something  
> we consider useful, but certain strings (e.g. ‘Proxied’) we do not  
> want to display to our clients.
>
> The application presenting error messages to the client has a  
> default string (with associated language translations) which is only  
> presented if a Reply-Message is not found.  Amending the application  
> to be more flexible with the replies it gets is currently not an  
> option.
>
> In the debug example below I’ve tried using a ReplyHook to delete  
> the relevant attribute from the reply if the value is equal to  
> ‘Proxied’, but the proxy adds it back in before sending the Access- 
> Reject back to the client.  Attempting to change it to another  
> string works as expected.
>
> Sample (handler) code excerpt:
>
> <Handler>
>        PreAuthHook sub { /
>               # attribute addition not shown
>        }
>        <AuthBy SQLRADIUS>
>               # host select and column definitions not shown
>               ReplyHook  sub { \
>                      &main::log($main::LOG_DEBUG, "Running  
> ReplyHook"); \
>                      my $rp = ${$_[1]}; \
>                      my $result = $rp->code; \
>                      my $reply = $rp->get_attr('Reply-Message'); \
>                      &main::log($main::LOG_DEBUG, "Result = $result,  
> Reply = $reply"); \
>                      if (($result eq 'Access-Reject') && ($reply eq  
> 'Proxied')) { \
>                            &main::log($main::LOG_DEBUG, "Deleting  
> Reply-Message attribute"); \
>                            $rp->delete_attr('Reply-Message'); \
>                            $reply = $rp->get_attr('Reply-Message'); \
>                            &main::log($main::LOG_DEBUG, "Reply:  
> $reply"); \
>                      } \
>               }
>        </AuthBy>
>        RejectHasReason
>        AccountingHandled
> </Handler>
>
> Tue Aug 11 13:23:15 2009: DEBUG: Running ReplyHook
> Tue Aug 11 13:23:15 2009: DEBUG: Result = Access-Reject, Reply =  
> Proxied
> Tue Aug 11 13:23:15 2009: DEBUG: Deleting Reply-Message attribute
> Tue Aug 11 13:23:15 2009: DEBUG: Reply:
> Tue Aug 11 13:23:15 2009: INFO: Access rejected for 123 at test.co.uk:  
> Proxied
> Tue Aug 11 13:23:15 2009: DEBUG: Packet dump:
> *** Sending to 10.46.0.1 port 1814 ....
> Code:       Access-Reject
> Identifier: 9
> Authentic:  <250><235>`<226>m<29><171>y<195><10><129>O<26><224>/<0>
> Attributes:
>         Reply-Message = "Proxied"
>         Proxy-State = 142
>
> I assume this the default behaviour.  Any ideas on how to achieve  
> such a conditional Reply-Message attribute deletion using Radiator?
>
> Regards,
>
> --
> Adnan Smajlovic
>
> The Cloud Networks Ltd.
> http://www.thecloud.net/more-information/contact-us
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.




More information about the radiator mailing list