Help desk support of authn/authz failures? Logging detailed messages to SQL?

[Jason Antman]

Thanks for the quick reply!

Alan Buxey wrote:
> hi,
>
> firstly, deployment tool - such as CloudPath xpressconnect or sux1 to ensure
> that the user is doing the least amount possible to mess things up (also ensures
> that all the right things such as validate server, RADIUS name etc are all properly
> defined).
>   
We use Cloudpath, but still have issues with either devices that get
gronked (iOS comes to mind) or devices that users attempt to "fix".
> secondly, capture the output of the logfile (Perl Tail File module is nice) - which
> is why I wanted the radiusd.log file to be the right one - logrotate really messes
> the recent 2.1.x logfile up - so i now have a manual restart of the server along
> with log rotation.....hmm..  and putting data (detail file stuff too) into  a database with
> a nice web front end for 'low level access' is a must.
>   
To put this nicely... our HD people can't deal with a logfile. They need
"if the box is red, read the "Reason" column next to it, and go to that
section in the wiki page." Unfortunately student labor isn't the best,
and those who are technically competent generally get jobs as sysprogs.
> there have been discussions in europe about way of logging the reason for a failure and
> putting it onto a sites secure web area so that users can log in and see why things arent
> working for them....
>   
Sounds like exactly what I need. Perhaps a patch to set an internal
control: attribute, which could then be logged however (for me,
Post-Auth Type Reject also goes to rlm_sql for logging, into such a
secure page).
> alan
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>