[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