(RADIATOR) Failure reason accessibility

[Hugh Irvine]

Hello Jeremy -

You could do something along the lines of what you show below by using 
an OSC-AVPAIR, but you will need to do some experiments as Reject 
handling is different and you may need to use a hook to manipulate the 
reply packet. There are some example hooks in the file 
"goodies/hooks.txt".

regards

Hugh


On Thursday, Oct 23, 2003, at 05:23 Australia/Melbourne, Jeremy Hinton 
wrote:

>
> Is there any way inside a <Handler> clause to access the reason for 
> the current requests failing, as it is accessible via %1 in an 
> <AuthLog> clause? I would like to be able to pass back the actual 
> failure reason to the client instead of the cryptic 
> Reply-Message="Request Denied".  Something along the lines of the 
> following, where %x is the var for the failure reason:
>
> <Handler>
> 	SessionDatabase	SDB_SQL
> 	AuthBy			Auth_SQL
>
> 	StripFromReply		Reply-Message
> 	AddToReply		Reply-Message=%x
> </Handler>
>
> The reason for this is we are migrating to using an AuthBy RADIUS 
> setup, where one server proxies to another. Unfortunately, on the 
> proxy/ front end server, the %1/Reason in an AuthLog SQL clause is 
> always set to "Proxy" on all login failures, instead of the normally 
> descriptive failure reason. I realize this is because the proxy server 
> has no way of knowing what the failure reason is from the server its 
> passing the request to. Hence, my need to have the back-end server 
> insert the failure text into the reply packet. Then i can structure 
> the AuthLog SQL insert statement on my front end server to log 
> '%{Reply:Reply-Message}' instead of %1 for the failure reason. Does 
> this make sense?
>
> - jeremy
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.