[RADIATOR] Logging specific AuthBy

[Hugh Irvine]

Hi Matt -

The trace 4 and trace 3 logs will show which AuthBy rejects the  
request, with the Identifier of the AuthBy if present.

You should also use "RejectHasReason" to automatically add a "Reply- 
Message = ....." to the reply, or you can add one manually in the  
AuthBy(s).

regards

Hugh


On 8 Oct 2009, at 14:00, Matt wrote:

> Thanks Hugh,
>
> Logging the handler Identifier works fine.  Just some clarification  
> on the automatic logging of AuthBy identifiers though. Where/when  
> would I expect to see the AuthBy identifiers logged automatically ?
>
> Regards,
>
> Matt.
>
> On Thu, Oct 8, 2009 at 7:28 AM, Hugh Irvine <hugh at open.com.au> wrote:
>
> Hi Matt -
>
> The simplest way to do this is to add Identifiers to your AuthBy's  
> and Handler's - the AuthBy Identifiers are logged automatically, and  
> you can log the Handler Identifiers like this:
>
>        %{Handler:Identifier}
>
> hope that helps
>
> regards
>
> Hugh
>
>
>
> On 7 Oct 2009, at 10:42, Matt wrote:
>
>
> Hi,
>
> I have an AuthBy group within a Handler which will ultimately catch  
> accounts disabled or with the wrong password and allow them in  
> regardless.  The purpose is to set some a cisco -avpairs to redirect  
> http traffic to a suitable error page so the user knows why they  
> cant connect...  This works great except I'm having trouble logging  
> this activity for the benefit of our helpdesk.
>
> So basically, I need a hook that can log which AuthBy  let the user  
> in so the helpdesk can tell whats happening. A trace4 does show what  
> I need but I dont obviously want to leave a trace4 running and let  
> our helpdesk see it.
>
> Ideally running a hook within the AuthBy would do the trick but I  
> cant run something like a PostAuthHook within an AuthBy.  It may  
> well be i need to rethink how this works entirely to achieve what I  
> need..
>
> Any thoughts on the subject would be appreciated.
>
> Thanks.
>
> Matt @ OntheNet
>
>
>
>
> _______________________________________________
> 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.
>
>
>



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.