Re: [RADIATOR] logging aborted EAP conversations
On 8/26/15 12:36 PM, David Zych wrote:
In theory it looks to me like it ought to be possible to add code to
Radius::Context::handle_timeout to examine the state of
$Radius::Context::contexts{$id} before it gets destroyed, decide if the
context state indicates an aborted conversation, and if so generate a
log message.
In practice, I'm not sure what fields within the context would be best
to examine. It looks like checking for the absence of
'handshake_finished' = 1 might be a good first pass to catch many
problem cases, but not necessarily all of them.
Any advice/ideas?
Below is what I've thrown together so far, and it seems to be doing some good,
getting me log messages like:
EAP TTLS context expired before handshake finished:
id=eap:D4-F4-6F-XX-XX-XX:x this_id=2 identity=x inner_identity=x
first_session_time=1440618940
Limitations of my current hack:
* This only detects if the EAP conversation aborts before the TLS handshake is
completed -- which anecdotally is most of what I'm seeing, but it would be nice
to be able to detect _any_ case in which the EAP conversation does not
complete, even if the problem occurs after the TLS handshake.
* I wish my log message could include additional fields from the last RADIUS
request that we did receive. In particular, Calling-Station-Id is conveniently
embedded in the id key, but I'd like to also be able to log the
Called-Station-Id and the NAS/Client IP (%c).
And of course it would be ideal if I could eventually do this with a Hook
instead of custom modifications to the actual Radiator code. :)
Thanks,
David
diff -ru radiator-20150716/radiator/lib/perl5/Radius/Context.pm
radiator-20150826.dmrz1/radiator/lib/perl5/Radius/Context.pm
--- radiator-20150716/radiator/lib/perl5/Radius/Context.pm 2013-09-06
07:58:44.0 -0500
+++ radiator-20150826.dmrz1/radiator/lib/perl5/Radius/Context.pm
2015-08-26 13:39:34.0 -0500
@@ -81,6 +81,32 @@
{
my ($handle, $id) = @_;
+#dmrz
+my $context = $Radius::Context::contexts{$id};
+if ($context-{eap_type} == 21) {
+ # detect and log aborted TTLS handshakes
+ unless ($context-{handshake_finished}) {
+my $msg = EAP TTLS context expired before handshake finished:;
+$msg .= $_=.(defined $context-{$_} ? $context-{$_} : )
+ foreach (qw(id this_id identity inner_identity first_session_time));
+main::log($main::LOG_WARNING, $msg);
+ }
+} elsif ($context-{eap_type} == 25) {
+ # detect and log aborted PEAP handshakes
+ unless ($context-{handshake_finished}) {
+my $msg = EAP PEAP context expired before handshake finished:;
+$msg .= $_=.(defined $context-{$_} ? $context-{$_} : )
+ foreach (qw(id this_id identity inner_identity first_session_time));
+main::log($main::LOG_WARNING, $msg);
+ }
+}
+## DEV ONLY!
+#use Data::Dumper;
+#open (my $fh, '', /scratch/dmrzhack.out);
+#print $fh localtime.\n.Dumper($context).\n;
+#close $fh;
+#/dmrz
+
destroy($id);
}
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging inner/outer identities
On 7 apr 2014, at 22:25, Hartmaier Alexander alexander.hartma...@t-systems.at
wrote:
I've just completed a very complex 802.1x setup and used
%{OuterRequest:User-Name} in the AuthLog FILE or the inner PEAP-TLS handler.
Thanks, that fixes my logging problems!
jakob
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
Hi Heikki, attached is what I just wrote, feedback welcome! Feel free to include it in the Radiator dist with an extended copyright, different name, ... Best regards, Alex On 2014-04-04 14:42, Heikki Vatiainen wrote: On 04/03/2014 12:28 PM, Hartmaier Alexander wrote: I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it is shared by different logging classes and defined in a base class. You are correct, there's no common class for LogFILE but the common class is LogGeneric instead. And since logs can be pushed to for example, SQL, LogFormat is only defined in LogFILE. I don't care so much where it is defined but how. Do you think configuring a Perl sub that returns a serialized string is the way to go for structured logging? I guess that would be like a in-line Hook? Maybe it could be configured as a hook type of parameter with a default value. See for example, SqlDb.pm and how ConnectionAttemptFailedHook is initialised with a default hook code. I was thinking about writing a Log module that uses Log::Any, Log4perl or Log::Dispatch so that you can do everything these modules support. My only concern is that the logging module affects Radiator and if e.g. RabbitMQ is down and logs can't be stored Radiator stops working. This might be intended if logging is an absolute requirement, but others might prefer availability over logging. Ideally this should be configurable. Indeed. As noted below, LogSQL can be configured with so that it won't make everything stop unless required so. What happens for the LogSQL class if the database goes down? It uses the functions defined in SqlDb.pm which for example, AuthBy SQL uses. Because of this, LogSQL respects FailureBackoffTime, Timeout and other common parameters AuthBy SQL uses. Is there some documentation how to write a Log class? I looks like It only has to have the ConfigKeywords hash, subclass from Radius::LogGeneric and an initialize and log sub. I'd say the existing Log* files are the best example. Is there anything special I need to do to allow a ConfigKeyword to hold a Perl sub? Maybe create it as a Hook? That should help not duplicating existing functionality. Thanks, Heikki BR Alex Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** LogStructured.pm Description: Perl program ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 04/03/2014 12:28 PM, Hartmaier Alexander wrote: I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it is shared by different logging classes and defined in a base class. You are correct, there's no common class for LogFILE but the common class is LogGeneric instead. And since logs can be pushed to for example, SQL, LogFormat is only defined in LogFILE. I don't care so much where it is defined but how. Do you think configuring a Perl sub that returns a serialized string is the way to go for structured logging? I guess that would be like a in-line Hook? Maybe it could be configured as a hook type of parameter with a default value. See for example, SqlDb.pm and how ConnectionAttemptFailedHook is initialised with a default hook code. I was thinking about writing a Log module that uses Log::Any, Log4perl or Log::Dispatch so that you can do everything these modules support. My only concern is that the logging module affects Radiator and if e.g. RabbitMQ is down and logs can't be stored Radiator stops working. This might be intended if logging is an absolute requirement, but others might prefer availability over logging. Ideally this should be configurable. Indeed. As noted below, LogSQL can be configured with so that it won't make everything stop unless required so. What happens for the LogSQL class if the database goes down? It uses the functions defined in SqlDb.pm which for example, AuthBy SQL uses. Because of this, LogSQL respects FailureBackoffTime, Timeout and other common parameters AuthBy SQL uses. Is there some documentation how to write a Log class? I looks like It only has to have the ConfigKeywords hash, subclass from Radius::LogGeneric and an initialize and log sub. I'd say the existing Log* files are the best example. Is there anything special I need to do to allow a ConfigKeyword to hold a Perl sub? Maybe create it as a Hook? That should help not duplicating existing functionality. Thanks, Heikki BR Alex Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2014-04-02 20:57, Heikki Vatiainen wrote: On 04/01/2014 02:59 PM, Hartmaier Alexander wrote: I think extending LogFormat is the right way to go because one might want to log to a file or database in json or yaml as well. What I still haven't figured out is a config format. Enabling to pass a Perl sub to LogFormat would be the most flexible option but not the most user friendly. Ideas? Wouldn't subclassing Log FILE work. Or maybe subclassing LogGeneric directly? I'd think keeping Log FILE as simple and straight forward would be a good goal since sometimes (Trace 4) a lot of traffic will pass through it. I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it is shared by different logging classes and defined in a base class. I don't care so much where it is defined but how. Do you think configuring a Perl sub that returns a serialized string is the way to go for structured logging? I was thinking about writing a Log module that uses Log::Any, Log4perl or Log::Dispatch so that you can do everything these modules support. My only concern is that the logging module affects Radiator and if e.g. RabbitMQ is down and logs can't be stored Radiator stops working. This might be intended if logging is an absolute requirement, but others might prefer availability over logging. Ideally this should be configurable. What happens for the LogSQL class if the database goes down? Is there some documentation how to write a Log class? I looks like It only has to have the ConfigKeywords hash, subclass from Radius::LogGeneric and an initialize and log sub. Is there anything special I need to do to allow a ConfigKeyword to hold a Perl sub? BR Alex Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 04/01/2014 02:59 PM, Hartmaier Alexander wrote: I think extending LogFormat is the right way to go because one might want to log to a file or database in json or yaml as well. What I still haven't figured out is a config format. Enabling to pass a Perl sub to LogFormat would be the most flexible option but not the most user friendly. Ideas? Wouldn't subclassing Log FILE work. Or maybe subclassing LogGeneric directly? I'd think keeping Log FILE as simple and straight forward would be a good goal since sometimes (Trace 4) a lot of traffic will pass through it. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2014-03-28 09:02, Hartmaier Alexander wrote:
On 2014-03-27 20:43, Heikki Vatiainen wrote:
On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:
Did you have time to work on this feature?
We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
not this. It's still on the ideas to explore list, though.
I've started tring to get all Radiator logs into Elasticsearch via
RabbitMQ and found out that Log FILE also closes the pipe in case of
Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
It makes the log files easy to rotate, but I can see why it's not good
in this case.
Because the logging script has some quite a 'high' startup time because
it has to connect to RabbitMQ and also disconnects immediatly afterwards
causing quite some overhead and RabbitMQ logging.
The comment in Radius::Util::append says:
# Current implementation opens, writes and closes
# Future implementations might hold the file open, and reopen on
# signal, or perhaps pipe to a daemon
I need a feature that keeps the spawned (forked?) process open and pipe
to it.
I'd also need to escape the log message so my JSON doesn't break in case
the message contains one or more .
LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
message:%2 }
Hmm, maybe a new class that could be configured to support the above? It
would need to be able to quote the log messages, maybe a configurable
method for different kinds of destinations (JSON, etc), hold the fd open
while supporting FarmSize and possibly something else too. I'd say
extending Log FILE may not be a good idea but to have a new logging class.
If you already have something that does what you require on the Log
... side, please get back to me directly.
Yeah, I was thinking about writing a LogMessagePassing or Log4perl class
but am not sure to which api I have to follow as its internal and as far
as I know undocumented.
For now I've created a named pipe which I configured Radiator to log to
and have a Message::Passing DSL script that runs as daemon using
Daemon::Control which uses the TailFile input and the AMQP output.
I wanted to not have to run that extra daemon because it's one more
thing that can go wrong.
I need a solution that outputs structed log messages serialized as JSON
fast.
My quick solution is:
Log FILE
# this is a named pipe created using mkfifo
Filename %L/radiator.fifo
LogFormat { timestamp:%Y-%m-%dT%H:%M:%SZ, source_host:%h,
priority:%1, type:radiator,
customer:%{OSC-Customer-Identifier}, message:%2 }
Trace 3
/Log
The problem is that some messages contain linefeeds (openssl library
errors when using EAP-TLS for example) which don't get escaped as per
JSON spec and make the JSON parsing fail.
I think extending LogFormat is the right way to go because one might
want to log to a file or database in json or yaml as well.
What I still haven't figured out is a config format.
Enabling to pass a Perl sub to LogFormat would be the most flexible
option but not the most user friendly.
Ideas?
Thanks,
Heikki
***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2014-03-27 20:43, Heikki Vatiainen wrote:
On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:
Did you have time to work on this feature?
We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
not this. It's still on the ideas to explore list, though.
I've started tring to get all Radiator logs into Elasticsearch via
RabbitMQ and found out that Log FILE also closes the pipe in case of
Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
It makes the log files easy to rotate, but I can see why it's not good
in this case.
Because the logging script has some quite a 'high' startup time because
it has to connect to RabbitMQ and also disconnects immediatly afterwards
causing quite some overhead and RabbitMQ logging.
The comment in Radius::Util::append says:
# Current implementation opens, writes and closes
# Future implementations might hold the file open, and reopen on
# signal, or perhaps pipe to a daemon
I need a feature that keeps the spawned (forked?) process open and pipe
to it.
I'd also need to escape the log message so my JSON doesn't break in case
the message contains one or more .
LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
message:%2 }
Hmm, maybe a new class that could be configured to support the above? It
would need to be able to quote the log messages, maybe a configurable
method for different kinds of destinations (JSON, etc), hold the fd open
while supporting FarmSize and possibly something else too. I'd say
extending Log FILE may not be a good idea but to have a new logging class.
If you already have something that does what you require on the Log
... side, please get back to me directly.
Yeah, I was thinking about writing a LogMessagePassing or Log4perl class
but am not sure to which api I have to follow as its internal and as far
as I know undocumented.
For now I've created a named pipe which I configured Radiator to log to
and have a Message::Passing DSL script that runs as daemon using
Daemon::Control which uses the TailFile input and the AMQP output.
I wanted to not have to run that extra daemon because it's one more
thing that can go wrong.
Thanks,
Heikki
***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2013-09-20 12:15, Hartmaier Alexander wrote:
On 2013-09-20 11:44, Heikki Vatiainen wrote:
On 09/20/2013 11:35 AM, Alexander Hartmaier wrote:
@Radiator guys: are you interessted in supporting Message::Passing,
Log::Log4perl or Log::Any?
They support a lot of outputs which would be a great feature addition!
Sounds interesting. So this would be for Accounting, at least first, or
do you see need for other passing other information through these too?
I'd prefer having this support for all types of logs.
Maybe extending Log to handle authentication, accounting and general
radiator logs would make sense.
AuthLog would become
Log MessagePassing (or all other currently available like Log FILE)
Auth 1
Acct 0
Other 0
...
/Log
If you don't want to change the config DSL so much the Log and AuthLog
stanzas would both need to support each output.
Haven't looked at the code yet but I guess there is much too share
between them and AuthLog could internally become just an alias for
LogAuth 1, Acct 0, Other 0.
Accounting logging is currently handled entirely different as there is
no AcctLog.
Did you have time to work on this feature?
I've started tring to get all Radiator logs into Elasticsearch via
RabbitMQ and found out that Log FILE also closes the pipe in case of
Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
The comment in Radius::Util::append says:
# Current implementation opens, writes and closes
# Future implementations might hold the file open, and reopen on
# signal, or perhaps pipe to a daemon
I need a feature that keeps the spawned (forked?) process open and pipe
to it.
I'd also need to escape the log message so my JSON doesn't break in case
the message contains one or more .
LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
message:%2 }
Thanks, Alex
As always, any additional ideas and comments from the list members would
be appreciated too.
Yes, please, speak up everybody!
***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 03/27/2014 05:22 PM, Hartmaier Alexander wrote:
Did you have time to work on this feature?
We have worked on EAP-SIM, Diameter and other RADIUS functionality, but
not this. It's still on the ideas to explore list, though.
I've started tring to get all Radiator logs into Elasticsearch via
RabbitMQ and found out that Log FILE also closes the pipe in case of
Filename |/etc/radiator/log_to_rabbitmq.pl which is a performance problem.
It makes the log files easy to rotate, but I can see why it's not good
in this case.
The comment in Radius::Util::append says:
# Current implementation opens, writes and closes
# Future implementations might hold the file open, and reopen on
# signal, or perhaps pipe to a daemon
I need a feature that keeps the spawned (forked?) process open and pipe
to it.
I'd also need to escape the log message so my JSON doesn't break in case
the message contains one or more .
LogFormat { timestamp:%Y-%m-%d %H:%M:%S, priority:%1,
message:%2 }
Hmm, maybe a new class that could be configured to support the above? It
would need to be able to quote the log messages, maybe a configurable
method for different kinds of destinations (JSON, etc), hold the fd open
while supporting FarmSize and possibly something else too. I'd say
extending Log FILE may not be a good idea but to have a new logging class.
If you already have something that does what you require on the Log
... side, please get back to me directly.
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
Hi Alexander, On 09/20/2013 10:35 AM, Alexander Hartmaier wrote: I expected that Radiator executes the configured program in a forked process once and expects it to read from STDIN in an event loop. Seems the program is executed for every log message. That's right, it's executed for every log message. What are your experiences with scaling and performance? I never noticed any performance problem. I just counted the radius accounting log messages (generated by this script on one server) we have per day: it's about 700 000. Max per second is around 60. On this server (with two multi-core CPUs) we have 8 radiator instances running (load balancing with iptables). But I agree, it would be better to have the possibility to log accounting messages to syslog one per line from inside radiator. :) Regards Klara -- Karlsruher Institut für Technologie (KIT) Steinbuch Centre for Computing (SCC) Klara Mall Netze und Telekommunikation (NET) Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen Telefon: +49 721 608-28630 Telefon: +49 721 608-48946 E-Mail: klara.m...@kit.edu Web: http://www.scc.kit.edu KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
Hi Klara, thanks for the script! I expected that Radiator executes the configured program in a forked process once and expects it to read from STDIN in an event loop. Seems the program is executed for every log message. What are your experiences with scaling and performance? @Radiator guys: are you interessted in supporting Message::Passing, Log::Log4perl or Log::Any? They support a lot of outputs which would be a great feature addition! On 2013-09-19 19:56, Klara Mall wrote: Hi Alexander, On 09/19/2013 04:57 PM, Alexander Hartmaier wrote: Since quite some time I'm looking for a way to customize the accounting log file format but the problem I'm having with it is that there seems to be no way to log all key/value pairs contained in the accounting packet without specifying each name. The default format is nice to read but hard to search with e.g. ack or grep. I've read that using pipe followed by a program as AcctLogFileName works but passing data serialized one log per line to it would also be easier for the program to parse the log and pass it on (e.g. JSON serialized). We ran into the same problem and wrote a perl script which we pipe the Accounting Log to. It's attached. radiator config: AcctLogFileName | /usr/local/bin/radacclog.pl Regards Klara -- Best regards, Alexander Hartmaier T-Systems Austria GesmbH TSS Security Services Network Security Monitoring Engineer phone: +43(0)57057-4320 fax: +43(0)57057-954320 *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 09/20/2013 11:35 AM, Alexander Hartmaier wrote: @Radiator guys: are you interessted in supporting Message::Passing, Log::Log4perl or Log::Any? They support a lot of outputs which would be a great feature addition! Sounds interesting. So this would be for Accounting, at least first, or do you see need for other passing other information through these too? As always, any additional ideas and comments from the list members would be appreciated too. -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
On 2013-09-20 11:44, Heikki Vatiainen wrote: On 09/20/2013 11:35 AM, Alexander Hartmaier wrote: @Radiator guys: are you interessted in supporting Message::Passing, Log::Log4perl or Log::Any? They support a lot of outputs which would be a great feature addition! Sounds interesting. So this would be for Accounting, at least first, or do you see need for other passing other information through these too? I'd prefer having this support for all types of logs. Maybe extending Log to handle authentication, accounting and general radiator logs would make sense. AuthLog would become Log MessagePassing (or all other currently available like Log FILE) Auth 1 Acct 0 Other 0 ... /Log If you don't want to change the config DSL so much the Log and AuthLog stanzas would both need to support each output. Haven't looked at the code yet but I guess there is much too share between them and AuthLog could internally become just an alias for LogAuth 1, Acct 0, Other 0. Accounting logging is currently handled entirely different as there is no AcctLog. As always, any additional ideas and comments from the list members would be appreciated too. Yes, please, speak up everybody! *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch
Hi Alexander, On 09/19/2013 04:57 PM, Alexander Hartmaier wrote: Since quite some time I'm looking for a way to customize the accounting log file format but the problem I'm having with it is that there seems to be no way to log all key/value pairs contained in the accounting packet without specifying each name. The default format is nice to read but hard to search with e.g. ack or grep. I've read that using pipe followed by a program as AcctLogFileName works but passing data serialized one log per line to it would also be easier for the program to parse the log and pass it on (e.g. JSON serialized). We ran into the same problem and wrote a perl script which we pipe the Accounting Log to. It's attached. radiator config: AcctLogFileName | /usr/local/bin/radacclog.pl Regards Klara -- Karlsruher Institut für Technologie (KIT) Steinbuch Centre for Computing (SCC) Klara Mall Netze und Telekommunikation (NET) Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen Telefon: +49 721 608-28630 Telefon: +49 721 608-48946 E-Mail: klara.m...@kit.edu Web: http://www.scc.kit.edu KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft radacclog.pl Description: Perl program ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging EAP method
Hello Stuart -
Have a look at the code in Radius/EAP.pm.
The EAPType is added to the current request as
$p-{EAPType}
and the name is added as
$p-{EAPTypeName}
You can easily write a little hook to use one or the other or both.
regards
Hugh
On 12 Jul 2013, at 04:32, Stuart Kendrick skend...@fhcrc.org wrote:
Is there a way to log the EAP method employed?
I'm doing this currently:
LogSuccess 1
SuccessFormat%l: wap: OK: %U: %n: %c: %{NAS-Identifier}: %T:
%{Calling-Station-Id}: %{Called-Station-Id}
LogFailure 1
FailureFormat%l: wap: FAIL: %U: %n: %c: %{NAS-Identifier}: %T:
%{Calling-Station-Id}: %{Called-Station-Id}
I was imagining something like %{EAP Method} ... but I don't see such a
token defined in Section 5.2 Special characters of the manual (pp.
20-24) ...
[I'm trying to figure out which clients are still using LEAP ... ergo my
desire to log the EAP method ...]
--sk
Stuart Kendrick
FHCRC
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] logging EAP method
Thank you Hugh
--sk
On 7/11/2013 7:03 PM, Hugh Irvine wrote:
Hello Stuart -
Have a look at the code in Radius/EAP.pm.
The EAPType is added to the current request as
$p-{EAPType}
and the name is added as
$p-{EAPTypeName}
You can easily write a little hook to use one or the other or both.
regards
Hugh
On 12 Jul 2013, at 04:32, Stuart Kendrick skend...@fhcrc.org wrote:
Is there a way to log the EAP method employed?
I'm doing this currently:
LogSuccess 1
SuccessFormat%l: wap: OK: %U: %n: %c: %{NAS-Identifier}: %T:
%{Calling-Station-Id}: %{Called-Station-Id}
LogFailure 1
FailureFormat%l: wap: FAIL: %U: %n: %c: %{NAS-Identifier}: %T:
%{Calling-Station-Id}: %{Called-Station-Id}
I was imagining something like %{EAP Method} ... but I don't see such a
token defined in Section 5.2 Special characters of the manual (pp.
20-24) ...
[I'm trying to figure out which clients are still using LEAP ... ergo my
desire to log the EAP method ...]
--sk
Stuart Kendrick
FHCRC
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Logging of multiple instances of attribute
Hello Jethro -
There is an example hook in goodies/hooks.txt that does the same thing for
multiple cisco-avpair attributes:
--
This hook is designed to parse multiple cisco-avpairs.
Contributed by:
chris.patter...@transact.com.au
All I'm doing here is taking each cisco-avpair attribute from the incoming
packet and adding new attributes onto the same incoming packet.
eg:
cisco-avpair = task_id=62
cisco-avpair = timezone=UTC
cisco-avpair = service=shell
cisco-avpair = priv-lvl=0
cisco-avpair = cmd=exit cr
become:
task_id = 62
timezone = UTC
service = shell
priv-lvl = 0
cmd = exit cr
Hope this assists people in their endeavours!
Cheers
Chris.
radiator.cfg
Handler
PreProcessingHook file:%D/createavpairs
AuthBy SQL
DBSourcedbi:mysql:radius
DBUsername test
DBAuth test
AccountingTable ACCOUNTING
AcctColumnDef TIMESTAMP,Timestamp,integer
AcctColumnDef NASIP,NAS-IP-Address
AcctColumnDef USERNAME,User-Name
AcctColumnDef CALLLINGID,Calling-Station-Id
AcctColumnDef PRIVLVL,priv-lvl
AcctColumnDef CMD,cmd
/AuthBy
/Handler
createavpairs
sub {
my $p=${$_[0]};
if (my @avpair = $p-get_attr('cisco-avpair')) {
foreach my $avpair (@avpair) {
$p-add_attr(split('=',$avpair));
}
}
}
--
You can modify it for Colubris-AVPAIR very easily.
regards
Hugh
On 18 Dec 2012, at 02:09, Jethro R Binks jethro.bi...@strath.ac.uk wrote:
I have devices which send Radiator multiple instance of a certain
attribute in their Access-Request. I want to print all of the values sent
for that attribute, but using a logging clause such as:
colubris-avp=%{Colubris-AVPAIR}
only shows me the first of the attributes received.
I went through the reference and couldn't find any recognition of this
issue.
Actually, I only really want one or two of the values to be honest. So it
would be really nice to be able to match on the A/V pair that I really
want, so maybe something like:
colubris-avp=%{Colubris-AVPAIR:ssid}
which will get me the correct string from a packet that looks like this in
part:
AVP: l=113 t=Vendor-Specific(26) v=Colubris(8744)
VSA: l=14 t=Colubris-AVPair(0): ssid=eduroam
VSA: l=23 t=Colubris-AVPair(0): incoming-vlan-id=4047
VSA: l=30 t=Colubris-AVPair(0): group=James Goold Hall (GLD)
VSA: l=17 t=Colubris-AVPair(0): vsc-unique-id=2
Any ideas?
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: (RADIATOR) Logging Assigned IP
Hello James - You probably want Framed-IP-Address. Check the RFC's for the attribute definitions (included in the Radiator distribution in doc/rfc2865.txt and doc/rfc2866.txt). regards Hugh What is the string I should use to log the IP that a customer is assigned after authenticating? I've dug through docs, but I can only find how to log the client IP the NAS IP, which is not what I want. I suppose if I knew what the field is called it might help :) Thanks, ::James Nelson --- -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS etc. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' 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 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging failed auth with postauthhook ?
Hello Adrian - I think I would be inclined to use a Log SQL clause, possibly in conjunction with a PacketTrace parameter. See section 6.12 in the Radiator 3.5 reference manual (doc/ref.html). regards Hugh Hi, I'm trying to set up a postauthhook.pl script that puts useful about login attempts into a mysql DB. I've currently got is showing successful connections and disconnections (and the reasons from Acct-Terminate-Cause), but can't get it to display failed authentication attempts at all because the authentication messages aren't available as attributes to the hook files.. Username's that don't exist don't show anything (radiator doesn't show any debugging info) and passwords that don't match valid username's are shown in debugging only.. My Handler config is below. Does anyone know how I can get bad login attempts logged with the postauthhook ? Regards, Adrian. Handler PreAuthHook file:%D/dsl_prehook.pl RewriteUsername s/^([^@]+).*/$1/ AuthByPolicy ContinueWhileAccept AuthBy CheckUsers AuthBy AllocateIPAddress AcctLogFileName /usr/local/lib/radius/acct/dsl-%Y-%m-%d AuthLog SQLLogger SessionDatabase SQLSDB PostAuthHook file:%D/dsl_posthook.pl /Handler --- -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS etc. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging IPASS accounting records to Database
Hello Tunde -
You just need to add an AuthBy SQL clause to your configuration file,
something like this:
Client localhost
# ipass client for VNAS (incoming metrong roamers)
Secret
Identifier ipassclient
IdenticalClients 63.10.10.212
RewriteUsername
s/^IPASS\/([^@]+)\@([^@]+)$/IPASS\/$1#$2\@myipass/
/Client
AuthBy RADIUS
Identifier ipassNetserver
Host 63.10.10.211
Secret
AuthPort 11812
AcctPort 11813
AddToRequest Called-Station-Id=%{Called-Station-Id},
NAS-IP-Address=%N
DefaultSimultaneousUse 1
/AuthBy
AuthBy SQL
Identifier SQLAccounting
DBSource .
DBUsername .
DBAuth .
# empty AuthSelect to disable authentication
AuthSelect
# configure AccountingTable and AcctColumnDef's
AccountingTable IPASSACCOUNTING
AcctColumnDef .
.
/AuthBy
Handler Realm=myipass
AcctLogFileName %L/ipass/detail
RewriteUsername
s/^IPASS\/([^#]+)\#([^@]+)\@myipass$/IPASS\/$1\@$2/
AuthByPolicy ContinueAlways
AuthBy SQLAccounting
AuthBy ipassNetserver
/Handler
Handler Client-Identifier=ipassclient
AuthByPolicy ContinueWhileAccept
RewriteUsername s/^([^@]+).*/$1/
RewriteUsername tr/A-Z/a-z/
UsernameCharset a-zA-Z0-9\._@-
AcctLogFileName %L/account.log
PasswordLogFileName %L/password.log
SessionDatabase SDB1
AuthBy SQLClientauth
StripFromReply Framed-IP-Address
/Handler
regards
Hugh
On Thursday, Jan 16, 2003, at 06:52 Australia/Melbourne, Ayotunde
Itayemi wrote:
Hi Hugh, Hi All,
I would like to log only IPASS accounting start and stop request to a
database
table so as to get some sort of record locally - how can I implement
this?
I want something a little bit simpler than the long detail file
generated by
the AcctLogFileName clause (see below pls). One can more easily peruse
entries in an Oracle table.
Regards,
Tunde Itayemi.
Relevant parts of my config :
Client localhost
# ipass client for VNAS (incoming metrong roamers)
Secret
Identifier ipassclient
IdenticalClients 63.10.10.212
RewriteUsername
s/^IPASS\/([^@]+)\@([^@]+)$/IPASS\/$1#$2\@myipass/
/Client
AuthBy RADIUS
Identifier ipassNetserver
Host 63.10.10.211
Secret
AuthPort 11812
AcctPort 11813
AddToRequest Called-Station-Id=%{Called-Station-Id},
NAS-IP-Address=%N
DefaultSimultaneousUse 1
/AuthBy
Handler Realm=myipass
AcctLogFileName %L/ipass/detail
RewriteUsername
s/^IPASS\/([^#]+)\#([^@]+)\@myipass$/IPASS\/$1\@$2/
AuthBy ipassNetserver
/Handler
Handler Client-Identifier=ipassclient
AuthByPolicy ContinueWhileAccept
RewriteUsername s/^([^@]+).*/$1/
RewriteUsername tr/A-Z/a-z/
UsernameCharset a-zA-Z0-9\._@-
AcctLogFileName %L/account.log
PasswordLogFileName %L/password.log
SessionDatabase SDB1
AuthBy SQLClientauth
StripFromReply Framed-IP-Address
/Handler
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging incorrect passwords with Authlog SQL
Hello Nicolai -
Yes, you can use the %P special character to give you the decoded
password in the SuccessQuery and/or FailureQuery (you may need to
upgrade however - Radiator 3.1 is the latest release - and there are
also some patches).
regards
Hugh
On Wednesday, August 14, 2002, at 10:39 PM, Nicolai van der Smagt wrote:
Hello,
Recently I moved our authentication logging to Authlog SQL. In the old
setup we had a PasswordLogFileName %L/ clause. When a user tried
logging in with a bad password, the password that the user used was
logged to the password logfile. This was nice because our users cannot
change the passwords in their routers. We changed the password in the
radius configuration, the router would come online, we changed the
password in the router and the radius server back to the correct value
- problem solved.
Is there a way to log the used password with Authlog SQL the way it
worked with PasswordLogFileName?
Radiator 2.19
AuthLog SQL
Identifier Radmin_authlog
DBSource dbi:mysql:radmin
DBUsername radmin
DBAuth
Table RADAUTHLOG
SuccessQuery insert into RADAUTHLOG values ('%1','%t','%0','%n')
FailureQuery insert into RADAUTHLOG values ('%1','%t','%0','%n')
LogSuccess 1
/AuthLog
Regards,
--
Nicolai van der Smagt UNIX Support Engineer
BBned NV. PO Box 692
2130 AR Hoofddorp phone +31 23 565
http://www.vandersmagt.nl/pgp-public-key.txt
Silence! Or I shall replace you with a very small shell script!
- The Wizard of OS
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Traffic
Hello Tim - In a trace 4 debug, Radiator only shows the attributes that it understands from the dictionary file (by definition). If you want to identifiy undefined attributes, you should run trace 5 and decode the hex dumps. BTW - the debug output should tell you what attribute number it can't find in the dictionary. Note that there are *lots* of new attribute definitions in Radiator 3.1. regards Hugh On Tue, 28 May 2002 01:12, Timothy G. Wells wrote: Greetings, When putting radiator into debug mode (v 2.18) does it show, in the details file, all the attributes or just the ones radiator knows from the dictionary? I'm trying to see what else is being sent to me. Thanks, -- Tim === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Active Handler
Hello Dan -
You would do something like this:
# define Handler with an Identifier
Handler .
Identifier SomethingDescriptive
...
/Handler
Then you would use this for logging:
%{Handler:Identifier}
regards
Hugh
On Fri, 3 May 2002 08:02, Dan Melomedman wrote:
Hi.
I need to log active handler identifier to the SQL table. In other words,
the handler where the failure occurs should be logged. What do I need to
do? I read documentation, but it's not exactly clear to me as how to do it.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Accounting to SQL without SQL authentication
Hello Dan - The AuthBy SQL clause is designed to do both authentication and accounting (which is how most people use it), however it is flexible enough to be configured in a number of ways including authentication only and accounting only. regards Hugh On Sun, 28 Apr 2002 04:50, Dan Melomedman wrote: Hugh Irvine writes: AuthBy SQL Identifier SQLAccounting .. AuthSelect AccountingTable ACCOUNTING AcctColumnDef . .. /AuthBy Handler . AuthByPolicy ContinueAlways AuthBy SQLAccounting AuthBy CheckLDAP . /Handler Thanks. It's great it works, but it's a work around. SQL accounting should be independent of AuthBy SQL. Next version maybe? :) -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Accounting to SQL without SQL authentication
Hugh Irvine writes: AuthBy SQL Identifier SQLAccounting .. AuthSelect AccountingTable ACCOUNTING AcctColumnDef . .. /AuthBy Handler . AuthByPolicy ContinueAlways AuthBy SQLAccounting AuthBy CheckLDAP . /Handler Thanks. It's great it works, but it's a work around. SQL accounting should be independent of AuthBy SQL. Next version maybe? :) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Accounting to SQL without SQL authentication
Hello Dan - You would do something like this: # define AuthBy clauses # normal LDAP authentication AuthBy LDAP2 Identifier CheckLDAP .. /AuthBy # SQL accounting only # (note empty AuthSelect to disable authentication) AuthBy SQL Identifier SQLAccounting .. AuthSelect AccountingTable ACCOUNTING AcctColumnDef . .. /AuthBy # define Realm(s) or Handler(s) # use AuthByPolicy ContinueAlways # SQLAccounting must appear before CheckLDAP Handler . AuthByPolicy ContinueAlways AuthBy SQLAccounting AuthBy CheckLDAP . /Handler regards Hugh On Sat, 27 Apr 2002 03:18, Dan Melomedman wrote: Hi. We want to log accounting to our SQL DB, but we are using LDAP DB for authentication. What can we do? AuthLog SQL doesn't mention AccountingTable functionality from AuthBy SQL. Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Infinite Loop?
Hello Steve - It may be useful to define a seperate Handler for adm so this doesn't happen. regards Hugh On Wed, 17 Apr 2002 09:13, Steve Brown wrote: Interesting thing happened today. When I enable Log EMERALD and the following ERR comes up: Tue Apr 16 13:55:41 2002: ERR: do failed for 'update ServerPorts set Username='adm', AcctSessionId='adm15375', AcctStatusType= case 'Start' wh en 'Start' then 1 when 'Stop' then 2 else 3 end, CallDate=getdate(), FramedAddress='', CallerId='', ConnectInfo='', ConnectionSpeed='', Modula tionType='', ModemTrainingTime=, ChassisCallSlot=, ChassisCallChannel=, DisconnectReason='', AccountTermCause='' where ServerID=(select Server ID from Servers where IPAddress='AAA.BBB.CCC.DDD') and Port=0': It proceeds to try to log (via Perl, FreeTDS, SyBase) - then the insert fails, so it logs that. The problem appears to be a failed insert returns more data, and then it tries logging the error via Log EMERALD, which returns even more data, then it tries to log that, and so on and so on and so on . until you kill -9 the server before it chews up all your RAM and slams the box to a halt. I think it has something to do with the single quotes. BTW, that ERR is perfectly acceptable - the AcctSQLStatement works just fine when someone dials in, it is only a problem when adm logs into the console which I don't care about (well, I do . but oh well) Steve -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) logging unstripped accounting
Nevermind, solved the problem. Seems like Radiator does not like the empty handler. Added the AuthBy NISPLUS to the empty handler and it worked. Don't know why it should though, since the authby won't be used to authenticate. hmmm ...??? -Original Message- From: Fred Albrecht Sent: 13 March 2002 11:53 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) logging unstripped accounting Hi I have a situation where I need to authenticate a user without his domain name, but I need to store the accounting info with the domain name. My problem is that if I do a rewrite of the username to strip the domain, then the accounting info also gets stripped. I've tried getting around this by specifying another handler to take care of the start and stop records, but then the connection to my database dies and no further accounting goes to the db. The test config to handle the start record, no auth needed: Handler Realm=domain, Acct-Status-Type=Start AcctLogFileName %L/%R/%d-%m-%y.log /Handler And then the actual authentication: Handler Realm=domain AuthBy NISPLUS Table passwd.org_dir Query [name=%U] AuthFieldDef passwd,Encrypted-Password,check /AuthBy AuthBy DBFILE Filename %D/users.db # Force it to use DB_File DBType DB_File /AuthBy AuthBy FILE Filename %D/users StripFromReply User-Category /AuthBy AcctLogFileName %L/%R/%d-%m-%y.log /Handler The error I get is: Wed Mar 13 11:41:15 2002: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='196.80.1.1' and NASPORT=01': ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute). Can anyone help? :) fred === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging unstripped accounting
Hello Fred - You can also use an AuthBy INTERNAL for this. And yes, you must have an AuthBy clause in a Realm or Handler. regards Hugh On Thu, 14 Mar 2002 01:24, Fred Albrecht wrote: Nevermind, solved the problem. Seems like Radiator does not like the empty handler. Added the AuthBy NISPLUS to the empty handler and it worked. Don't know why it should though, since the authby won't be used to authenticate. hmmm ...??? -Original Message- From: Fred Albrecht Sent: 13 March 2002 11:53 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) logging unstripped accounting Hi I have a situation where I need to authenticate a user without his domain name, but I need to store the accounting info with the domain name. My problem is that if I do a rewrite of the username to strip the domain, then the accounting info also gets stripped. I've tried getting around this by specifying another handler to take care of the start and stop records, but then the connection to my database dies and no further accounting goes to the db. The test config to handle the start record, no auth needed: Handler Realm=domain, Acct-Status-Type=Start AcctLogFileName %L/%R/%d-%m-%y.log /Handler And then the actual authentication: Handler Realm=domain AuthBy NISPLUS Table passwd.org_dir Query [name=%U] AuthFieldDef passwd,Encrypted-Password,check /AuthBy AuthBy DBFILE Filename %D/users.db # Force it to use DB_File DBType DB_File /AuthBy AuthBy FILE Filename %D/users StripFromReply User-Category /AuthBy AcctLogFileName %L/%R/%d-%m-%y.log /Handler The error I get is: Wed Mar 13 11:41:15 2002: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='196.80.1.1' and NASPORT=01': ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute). Can anyone help? :) fred === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging into network
Please ignore this message. We found out the error. Much thanks. Regards, Neil D. Quiogue Information and attachments herein are intended for the named recipients only. It may contain attorney-client privileged or confidential matter. If you have received this message in error, please notify the sender immediately, and destroy the original message. Do not disclose the contents to anyone. Thank you. - Original Message - From: neil d. quiogue [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 14, 2002 7:22 AM Subject: (RADIATOR) Logging into network Greetings, Here's the situation. We've migrated one old RADIUS server to Radiator and everything works out properly except that for some reason, whenever it authenticates properly, the 'Logging into network...' message from MS DUN takes longer than usual to finish. I mean I'm receiving the accounting record fast enough. And the network is up (even if the dialog box takes forever). Anyone experienced this before and knew what configuration to tweak? We didn't experience this on the old RADIUS server. If anyone has tips, it would be great. Regards, Neil D. Quiogue Information and attachments herein are intended for the named recipients only. It may contain attorney-client privileged or confidential matter. If you have received this message in error, please notify the sender immediately, and destroy the original message. Do not disclose the contents to anyone. Thank you. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging into network
Have the customer uncheck log on to network in the dun settings, There is also some type of compression that you can enable in the NAS that will help this as well Thanks, Tony B, CCNA, Network+ Systems Administration GO Concepts, Inc. / www.go-concepts.com Are you on the GO yet? What about those you know, are they on the GO? 513.934.2800 1.888.ON.GO.YET -Original Message- From: neil d. quiogue [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 6:22 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Logging into network Greetings, Here's the situation. We've migrated one old RADIUS server to Radiator and everything works out properly except that for some reason, whenever it authenticates properly, the 'Logging into network...' message from MS DUN takes longer than usual to finish. I mean I'm receiving the accounting record fast enough. And the network is up (even if the dialog box takes forever). Anyone experienced this before and knew what configuration to tweak? We didn't experience this on the old RADIUS server. If anyone has tips, it would be great. Regards, Neil D. Quiogue Information and attachments herein are intended for the named recipients only. It may contain attorney-client privileged or confidential matter. If you have received this message in error, please notify the sender immediately, and destroy the original message. Do not disclose the contents to anyone. Thank you. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to MSSQL 7.0
Hugh Irvine writes: BTW - you say that Radiator is *almost* perfect - we would be keen to hear any suggestions for improvements. regards Hugh Hi Hugh, AuthLog Pipe: I'd like to be able to fork an external program, and pipe the log data to it for logging, instead of logging directly to a file. I'd like to use the daemontools' 'multilog' since it does nice log rotation and TAI timestamping. Is there some way to rotate logs in Radiator? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging to MSSQL 7.0
Here is my conf: # radius.cfg # # You should consider this file to be a starting point only # $Id: linux-radius.cfg,v 1.2 2001/08/30 03:41:02 mikem Exp $ #Foreground #LogStdout LogDir /var/log/radius DbDir /etc/radiator DictionaryFile %D/dictionary # Use a low trace level in production systems. Increase # it to 4 or 5 for debugging, or use the -trace flag to radiusd Trace 3 #Lower case RewriteUsername tr/A-Z/a-z/ #Remove Spaces RewriteUsername s/\s+//g ClientListSQL #this is part of the MS SQL database DBSource DBI:Sybase:database=databasename;server=server DBUsername username DBAuth x GetClientQuery select NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL,DEFAULTREALM,NASTYP E,SNMPCOMMUNITY,LIVINGSTONOFFS,LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS,FRA MEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME,NOIGNOREDUPLICATES,PREHANDLERH OOK from NASClients /ClientListSQL SessionDatabase SQL DBSource dbi:mysql:radius:xxx.xxx.xxx.xxx DBUsername radiusd DBAuth ch2900 /SessionDatabase Handler Realm=go-concepts.com,Request-Type=Access-Request RewriteUsername s/^([^@]+).*/$1/ AuthBy SQL Identifier GOCsql DefaultReply Ascend-Shared-Profile-Enable=0,User-Service=Framed-User,Framed-Protocol= PPP,Framed-Routing=None,Ascend-Base-Channel-Count=1,Ascend-Minimum-Chann els=1,Ascend-Maximum-Channels=1,Ascend-Assign-IP-Pool=1,Ascend-Multicast -Client=Multicast-Yes DBSource DBI:Sybase:database=datbasename;server=server DBUsername username DBAuth x AuthSelect AuthSelect %n AuthColumnDef 0, User-Password, check AuthColumnDef 1, Framed-Address, reply AuthColumnDef 2, Framed-Protocol, reply AuthColumnDef 3, Ascend-Maximum-Channels, reply AuthColumnDef 4, Ascend-IP-Direct, reply AuthColumnDef 5, Ascend-Assign-IP-Pool, reply AuthColumnDef 6, GENERAL, reply AddToReplyIfNotExist User-Service=Framed-User,Framed-Protocol=PPP,Framed-Routing=None,Ascend- Base-Channel-Count=1,Ascend-Minimum-Channels=1,Ascend-Maximum-Channels=1 ,Ascend-Assign-IP-Pool=1,Ascend-Multicast-Client=Multicast-Yes /AuthBy SQL /Handler Handler Request-Type=Accounting-Request AuthBy SQL Identifier MySQL DBSource dbi:mysql:radius:xxx.xxx.xxx.xxx DBUsername username DBAuth x AuthSelect AcctColumnDef USERNAME,%n,formatted AcctColumnDef TIME_STAMP,Timestamp,integer AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer AcctColumnDef ACCTSESSIONID,Acct-Session-Id AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause AcctColumnDef NASIDENTIFIER,NAS-Identifier AcctColumnDef NASPORT,NAS-Port,integer /AuthBy SQL /Handler We do several rewrites to the username, that is why we us %n for the username field, that way you see the formatted username after all the rewrites occur. The Accounting Request are all logged into the mysql server. You can define what you want logged into what columns using the AcctColumnDef command. We are not yet using this in a production server but we have tested it may time and it works great. If you have any questions feel free to ask. Thanks, Tony B, CCNA, Network+ Systems Administration GO Concepts, Inc. / www.go-concepts.com Are you on the GO yet? What about those you know, are they on the GO? 513.934.2800 1.888.ON.GO.YET -Original Message- From: Shane Malden [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 10, 2002 11:51 PM To: tonyb Subject: Re: (RADIATOR) Logging to MSSQL 7.0 Tony, I would be interested on more information on how to do accounting with SQL. We use Radiator 2.19 and authenticate with SecurID. We don't have any direct control over our NAS as they are supported by out Telecommunications provider. I would be very interested in finding out how to see what data and time users are connecting for. If your able to help, it would be appreciated. Regards, Shane - Original Message - From: tonyb [EMAIL PROTECTED] To: Dan Melomedman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 11, 2002 2:38 PM Subject: RE: (RADIATOR) Logging to MSSQL 7.0 We are an ISP that just recently evaluated and purchased radiator. And I agree that it is a great radius program...anyway back to sql We use
Re: (RADIATOR) Logging to MSSQL 7.0
Hello Dan - On Sun, 10 Mar 2002 06:04, Dan Melomedman wrote: First, let me add my praise about this product to the already long list. We're evaluating Radiator. This is the best commercial server product I have ever dealt with, great job! Finally a RADIUS server that's almost, if not, perfect. Rock on! Anyway, we use FreeTDS for PHP scripts, and some things work, some break and cause segfaults depending on the features we're trying to use through FreeTDS. As much as I hate logging to the database, some of our existing reporting scripts (VB Script) require it anyway, so this is a part of evaluation as well. Do any of you on this list log to an MSSQL database from a Unix variant with FreeTDS library? Any caveats? Thanks much. FreeTDS is known to have a few problems. In general you are better off using a commercial ODBC driver. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging failed authentication attempts
Terry, Check out Section 6.47 in the Radiator manual. It is on AuthLog. That should be what you are looking for. -Ronan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Friday, 15 February, 2002 12:26 To: [EMAIL PROTECTED] Subject: (RADIATOR) Logging failed authentication attempts Hi. I looked through the archives, and it appears that logging failed authentication attempts has been a wish-list item for a while, I'm curious if there is a method in the newer versions of radiator. Thanks, Terry Ryan === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging failed authentication attempts
As a bonus, here's what we do:
#
AuthLog FILE
Identifier AUTH_LOGGER
Filename%D/Authentication/%R-%h
LogSuccess 1
LogFailure 1
# Note the literal tab characters:
SuccessFormat %l%r\
User-Name = %U%r\
Pass = 1%r \
CallerId = %{Calling-Station-Id}%r \
Typed-Password = %P%r \
Severity = %0%r \
Reason = %1%r%r
FailureFormat %l%r\
User-Name = %U%r\
Pass = 0%r \
CallerId = %{Calling-Station-Id}%r \
Typed-Password = %P%r \
Severity = %0%r \
Reason = %1%r%r
/AuthLog
#
This formats it exactly like a Radius accounting packet! Then we use the
same process to import this info in near real-time to our SQL database
as we do for Accounting data. The CallerId is immeasurably handy when
they're mistyping the username and password or if the username comes in
all garbled due to line noise.
Tech support LOVES it :)
Dave
p.s. Before those \ characters are supposed to be literal tabs, not
spaces.
-Original Message-
From: Ronan Eckelberry [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 1:18 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Logging failed authentication attempts
Terry,
Check out Section 6.47 in the Radiator manual. It is on
AuthLog. That should be what you are looking for.
-Ronan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, 15 February, 2002 12:26
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Logging failed authentication attempts
Hi. I looked through the archives, and it appears that
logging failed authentication attempts has been a wish-list
item for a while, I'm curious if there is a method in the
newer versions of radiator.
Thanks,
Terry Ryan
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging failed authentication attempts
I do the same kinda thing. I parse it into a webpage for them
to look at though. You know that AuthLog supports logging to SQL, that
way you don't have to run a script to put it in.
-Ronan
-Original Message-
From: Dave Kitabjian [mailto:[EMAIL PROTECTED]]
Sent: Friday, 15 February, 2002 14:30
To: Ronan Eckelberry; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Logging failed authentication attempts
As a bonus, here's what we do:
#
AuthLog FILE
Identifier AUTH_LOGGER
Filename%D/Authentication/%R-%h
LogSuccess 1
LogFailure 1
# Note the literal tab characters:
SuccessFormat %l%r\
User-Name = %U%r\
Pass = 1%r \
CallerId = %{Calling-Station-Id}%r \
Typed-Password = %P%r \
Severity = %0%r \
Reason = %1%r%r
FailureFormat %l%r\
User-Name = %U%r\
Pass = 0%r \
CallerId = %{Calling-Station-Id}%r \
Typed-Password = %P%r \
Severity = %0%r \
Reason = %1%r%r
/AuthLog
#
This formats it exactly like a Radius accounting packet! Then we use the
same process to import this info in near real-time to our SQL database
as we do for Accounting data. The CallerId is immeasurably handy when
they're mistyping the username and password or if the username comes in
all garbled due to line noise.
Tech support LOVES it :)
Dave
p.s. Before those \ characters are supposed to be literal tabs, not
spaces.
-Original Message-
From: Ronan Eckelberry [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 1:18 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Logging failed authentication attempts
Terry,
Check out Section 6.47 in the Radiator manual. It is on
AuthLog. That should be what you are looking for.
-Ronan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, 15 February, 2002 12:26
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Logging failed authentication attempts
Hi. I looked through the archives, and it appears that
logging failed authentication attempts has been a wish-list
item for a while, I'm curious if there is a method in the
newer versions of radiator.
Thanks,
Terry Ryan
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging
Hello Shane - You should use an AuthLog clause (section 6.47 in the Radiator 2.19 manual). regards Hugh On Thu, 7 Feb 2002 14:46, Shane Malden wrote: I am looking to have all Successful attempts logged. Current we have trace 3 and we only get unsuccessful attempts logged. Could some one advised how we can log the successful attempts. Regards, Shane -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging in a database with a proxying realm
Hello Alex -
I suspect there may be some confusion in what you are trying to do.
An AuthLog SQL clause will only log authentication requests, not accounting
requests, and your configuration below looks like you want to record
accounting requests.
If you do want to log accounting records, here is how to do it.
###
Realm always-onlineusa.com
AuthByPolicy ContinueAlways
# configure AuthBy SQL clause for accounting only
# note empty AuthSelect to disable authentication
AuthBy SQL
DBSourcedbi:Oracle:ncnora
DBUsername radius_21globe
DBAuth 123456
AuthSelect
AccountingTable RADIUS_21GLOBE.ACCOUNTING
DateFormat %a %b %e, %Y %I:%M %p
AcctColumnDef USERNAME, '%{User-Name}'
AcctColumnDef TIME_STAMP, %{Timestamp}, integer
AcctColumnDef LOGDATESTR, '%{Timestamp}', integer-date
AcctColumnDef ACCTSTATUSTYPE, '%{Acct-Status-Type}'
AcctColumnDef ACCTDELAYTIME, %{Acct-Delay-Time}
AcctColumnDef ACCTINPUTOCTETS, %{Acct-Input-Octets}, integer
AcctColumnDef ACCTOUTPUTOCTETS, %{Acct-Output-Octets}, integer
AcctColumnDef ACCTSESSIONID, '%{Acct-Session-Id}'
AcctColumnDef ACCTSESSIONTIME, %{Acct-Session-Time}, integer
AcctColumnDef ACCTTERMINATECAUSE, %{Acct-Terminate-Cause}
AcctColumnDef NASIDENTIFIER, '%{NAS-Identifier}'
AcctColumnDef NASPORT, %{NAS-Port}, integer
AcctColumnDef FRAMEDIPADDRESS, '%{Framed-IP-Address}'
AcctColumnDef CALLINGSTATIONID, '%{Calling-Station-Id}'
AcctColumnDef CALLSTATIONID, '%{Called-Station-Id}'
/AuthBy
AuthBy RADIUS
Host 63.252.251.119
Secret ncn123456
AuthPort 1814
AcctPort 1815
/Host
/AuthBy
# Log accounting to a detail file
AcctLogFileName ./logs/always-online.detail
/Realm
##
hth
Hugh
Hey guys,
Just need a little help here. We have some realms that are passing
through our radius server. The actual authentication takes place at their
server but we are the server the NAS looks to. We set it up to AuthBy
RADIUS and that works great. The problem is that we want to log the users
that authenticate or fail to that realm. We need to figure out how to
insert the packets into our database.
We tried using AuthLog SQL but were having difficulties getting it work
correctly. This is the piece of the config file we are having problems
with:
###
Realm always-onlineusa.com
AuthByPolicy ContinueWhileAccept
AuthBy RADIUS
Host 63.252.251.119
Secret ncn123456
AuthPort 1814
AcctPort 1815
/Host
/AuthBy
AuthLog SQL
DBSourcedbi:Oracle:ncnora
DBUsername radius_21globe
DBAuth 123456
LogSuccess 1
Table ACCOUNTING
DateFormat %a %b %e, %Y %I:%M %p
SuccessQuery insert into RADIUS_21GLOBE.ACCOUNTING \
(USERNAME, TIME_STAMP, LOGDATESTR, ACCTSTATUSTYPE,
ACCTDELAYTIME, \
ACCTINPUTOCTETS, ACCTOUTPUTOCTETS, ACCTSESSIONID,
ACCTSESSIONTIME, \
ACCTTERMINATECAUSE, NASIDENTIFIER, NASPORT, FRAMEDIPADDRESS, \
CALLINGSTATIONID, CALLSTATIONID) \
values \
('%{User-Name}', %{Timestamp,integer}, \
'%{Timestamp,integer-date}', '%{Acct-Status-Type}', \
%{Acct-Delay-Time}, %{Acct-Input-Octets,integer}, \
%{Acct-Output-Octets,integer}, '%{Acct-Session-Id}', \
%{Acct-Session-Time,integer}, %{Acct-Terminate-Cause}, \
'%{NAS-Identifier}', %{NAS-Port,integer}, \
'%{NAS-IP-Address}', '%{Calling-Station-Id}', \
'%{Called-Station-Id}')
/AuthLog
# Log accounting to a detail file
AcctLogFileName ./logs/always-online.detail
/Realm
##
Problem is that some of the values that come from the Special string
formatting characters are coming back null (which needs to be fixed because
we need those values) and this causes the SQL statement to fail. Please
help, we need to have these logs in our database and not in text files on
the radius server. Thanks.
Alex Fritz
[EMAIL PROTECTED]
Kerdaino Enterprises, Inc.
Mobile, AL USA
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.307 / Virus Database: 168 -
Re: (RADIATOR) Logging question
Hello Steve -
On Tuesday 23 October 2001 05:12, Stephen Caporossi wrote:
I am trying to setup radiator to log our VPN users to a different file
than PPP users. We have several PPP and VPN servers and I do not want
each to log to it's own file. Is there a way to do this? Is there some
method of putting a name/variable, such as PPP or VPN in the client
clause that logging can key on?
Do something like this:
# define DbDir
DbDir /var/log/radius
# define log file using %{Client:Identifier} and date
# NB - you can arrange this to suit
LogFile %D/%{Client:Identifier}/logfile-%Y-%m-%d
# define Client clauses
Client n.n.n.n
Identifier PPP
.
/Client
Client m.m.m.m
Identifier VPN
.
/Client
.
Have a look at section 6.2 in the Radiator 2.18.4 reference manual.
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging elapsed time?
Hello Griff - On Tuesday 18 September 2001 07:36, Griff Hamlin, III wrote: Hello, Is there anyway to log in trace mode 3 the amount of time that elapses between when radiusd receives an auth request and it actually responds to it? Thanks. The only way I can think of to do this is with a PreClientHook and a PostAuthHook, however you will probably need to use the LogMicroseconds parameter and the Time::HiRes module as most responses will be sub-second. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to file without open/close per message
Hello Steinar - We log out Radiator account messages to file, with the LogFile keyword. However, both this and Log FILE results in the logfile being opened and closed once per message logged. As far as we can see, this is a reasonably significant source of overhead. I know we can use SYSLOG logging, but it seems to me we would get the least amount of overhead by logging to a file which was kept open all the time (only closed for log rotation). Is there an easy way to do this? Radiator opens, writes and closes all files (logging, accounting, etc). As you say, you can either use a Log SYSLOG, or Log SQL. BTW - most of our customers use the Log SQL and log to the same database as they use for customer information and accounting. regards Hugh -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to SQL DB
Hello Magnus - The answer to this depends somewhat on what else you are doing, however here is one way to do it. # define AuthBy clauses AuthBy SQL Identifier SQLAccounting DBSource ... DBUsername DBAuth . # empty AuthSelect (no authentication) AuthSelect AccountingTable ACCOUNTING AcctColumnDef . AcctColumnDef . . /AuthBy AuthBy RADIUS Identifier ForwardToProxy . /AuthBy # define Realms or Handlers Realm AuthByPolicy ContinueAlways AuthBy SQLAccounting AuthBy ForwardToProxy . /Realm This is a simple example and much more sophisticated configurations are possible of course. hth Hugh On Wednesday 29 August 2001 11:12, Magnus E. Sigurdsson wrote: Hi, Is it possible to set up Radiator in such a way so that I can get it to authenticate by one method and log accounting to an SQL DB? Specifically I need to proxy authentication requests to another Radius server using AuthBy Radius but I'd still like to log to our MS SQL 7 DB. Thanks, Magnus E. Sigurdsson Network Administrator Hringidan ehf. / Vortex Inc. Content-Type: text/html; charset=Windows-1252; name=Attachment: 1 Content-Transfer-Encoding: quoted-printable Content-Description: -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging multiple access?
Hello Brett - The log file will show this and you can also set up additional AuthLog ... clauses. See section 6.43 in the Radiator 2.18 reference manual. BTW - I encourage you to read the manual thoroughly at least once. regards Hugh At 11:19 +1000 01/3/28, Brett Murphy wrote: Hi All, I have enabled MaxSessions 1, how do I see who is trying to login in twice? -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging accounting to a seperate server?
Hello Jamie - At 15:55 -0500 01/2/21, Jamie Orzechowski wrote: Hello ... I would like to know if it's possible to authenticate via one method (AuthBy FILE) and do accounting via AuthBy RODOPI so all auth requests are handled via Auth FILE and all Accounting requests are handled via AuthBy RODOPI any ideas how this can be done? Very easily with Handlers: # configure Handler for accounting Handler Request-Type = Accounting-Request .. /Handler # configure Handler for authentication Handler . /Handler hth Hugh -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) logging accounting to a seperate server?
You can take care of the accounting first in a Handler Request-Type = Accounting-Request Then you have an unconconditional handler that picks up what's left, i.e. authentication requests. And while you're at it, you might consider splitting into two processes, one for authentication (AuthPort 1812, AcctPort empty) and the other for accounting (AcctPort 1813, AuthPort empty) /Ingvar -Original Message- From: Jamie Orzechowski [mailto:[EMAIL PROTECTED]] Sent: den 22 februari 2001 04:14 To: [EMAIL PROTECTED] Subject: (RADIATOR) logging accounting to a seperate server? Hello ... I would like to know if it's possible to authenticate via one method (AuthBy FILE) and do accounting via AuthBy RODOPI so all auth requests are handled via Auth FILE and all Accounting requests are handled via AuthBy RODOPI any ideas how this can be done? === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging IP Addresses
Hello Eric - On Saturday 27 January 2001 06:36, Eric Elliston wrote: I am using Platypus (SQL 7.0 Database) to store all my radius information. I need to be able to set it up where I can also log the IP address a user is assigned when he logs onto our system. What module does the reporting to the SQL database? You can use the AcctColumnDef statement in the AuthBy PLATYPUS clause. Have a look at section 6.30 in the Radiator 2.17.1 reference manual (you can also have a look at the module "Radius/AuthPLATYPUS.pm). hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
IMPORTANT - Re: (RADIATOR) Logging of password in Radiator 2.17.1
Hello Jamie - On Wed, 29 Nov 2000, Jamie Orzechowski wrote: Hello! ... I just upgraded to 2.17.1 Our old radius used to log the password typed by the user which was very informative for tech support purposes ... I was wondering if anyone know how to do this in radiator via a .cfg file or what to modify in the .pm modules to make this work ... any ideas? I would like to have it show the password typed in when there is a failure and not when a user is authenticated successfully ... any ideas would be appreciated ... thanks ... Check out the new AuthLog clause, sections 6.40, 6.41 and 6.42 in the manual. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Timestamp
Hello Anton - On Thu, 12 Oct 2000, Anton Sparrius wrote: Hi, When logging Radiator timestamps each log entry as : Thu Oct 12 19:01:42 2000: I need to get this to show more accuracy than just seconds. The code is in LogFILE.pm which says : my $ctime = localtime(time); my $message = "$ctime: $Radius::Log::priorityToString[$p]: $s\n"; These are the standard Perl times in seconds, so no, not with the standard routines. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging stops while server appears to be still working
Hello everyone, I am having the same problems that Paul is having. We recently upgraded from Radiator 2.13 on Solaris 2.6 to Radiator 2.16.1 on Solaris 2.7. While we have had no problems at all with authentication, our logging seems to quit on us after just a few hours. The logfile consistently ends with: Fri Aug 11 18:00:12 2000: DEBUG: Handling request with Handler 'Realm=DEFAULT' Fri Aug 11 18:00:12 2000: DEBUG: Rewrote user name to pirnae Fri Aug 11 18:00:12 2000: DEBUG: Deleting session for pirnae, 142.66.14.3, 6 Fri Aug 11 18:00:12 2000: DEBUG: Handling with Radius::AuthLDAP Fri Aug 11 18:00:12 2000: DEBUG: Connecting to deimos.online.uleth.ca, port 389 Where "pirnae" is one of our users (this is always different) and 142.66.14.3 is the IP of one of our modem pools. The machine "deimos" is where our ldap is located. Our radldap.cfg file (without secrets) looks like this: Foreground Trace 4 PidFile /tmp/radiusd.pid AuthPort1645 AcctPort1646 LogDir . DbDir . LogFile %L/radius-user-logfile Client DEFAULT DupInterval 0 /Client Realm DEFAULT RewriteUsername s/^([^@]+).*/$1/ RejectHasReason AuthBy LDAP Hostdeimos.online.uleth.ca Port 389 BaseDN o=University of Lethbridge, c=CA UsernameAttruid PasswordAttrulmodempasswd /AuthBy /Realm Any ideas on what is causing this? Again, we can get by without a fix, but it would be nice to have something in our logs! Thanks. - jim savoy - PS We have not applied any of the patches. I read the readme file in the patch directory and none of the fixes seemed to apply to our situation. I am having a weird problem with Radiator 2.16.1 on Solaris 2.6 I am running a split setup using separate Accounting and Authenticating servers. It looks like the auth server stops logging until killed while still doing authentication. The log looks like: Sat Aug 12 22:43:52 2000: DEBUG: Handling with Radius::AuthLDAP2 Sat Aug 12 22:43:52 2000: DEBUG: Connecting to ldap.whepp.nl, port 389 Sun Aug 13 16:41:11 2000: DEBUG: Reading users file /etc/opt/radius/users Sun Aug 13 16:41:13 2000: INFO: Server started: Radiator 2.16.1 If I look at the ldap logs I still see connections coming in on the LDAP server. The accounting server also sees Start and Stop accounting records. I am not using any special naming in the logfile name, just a 'LogDir /var/radius' line. Paul === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging stops while server appears to be stillworking
Hello James - The log below appears to show that the LDAP server has stopped responding for some reason. I have copied this mail to Mike to see if he has any ideas. regards Hugh At 14:36 -0600 28/8/00, James Savoy wrote: Hello everyone, I am having the same problems that Paul is having. We recently upgraded from Radiator 2.13 on Solaris 2.6 to Radiator 2.16.1 on Solaris 2.7. While we have had no problems at all with authentication, our logging seems to quit on us after just a few hours. The logfile consistently ends with: Fri Aug 11 18:00:12 2000: DEBUG: Handling request with Handler 'Realm=DEFAULT' Fri Aug 11 18:00:12 2000: DEBUG: Rewrote user name to pirnae Fri Aug 11 18:00:12 2000: DEBUG: Deleting session for pirnae, 142.66.14.3, 6 Fri Aug 11 18:00:12 2000: DEBUG: Handling with Radius::AuthLDAP Fri Aug 11 18:00:12 2000: DEBUG: Connecting to deimos.online.uleth.ca, port 389 Where "pirnae" is one of our users (this is always different) and 142.66.14.3 is the IP of one of our modem pools. The machine "deimos" is where our ldap is located. Our radldap.cfg file (without secrets) looks like this: Foreground Trace 4 PidFile /tmp/radiusd.pid AuthPort1645 AcctPort1646 LogDir . DbDir . LogFile %L/radius-user-logfile Client DEFAULT DupInterval 0 /Client Realm DEFAULT RewriteUsername s/^([^@]+).*/$1/ RejectHasReason AuthBy LDAP Hostdeimos.online.uleth.ca Port 389 BaseDN o=University of Lethbridge, c=CA UsernameAttruid PasswordAttrulmodempasswd /AuthBy /Realm Any ideas on what is causing this? Again, we can get by without a fix, but it would be nice to have something in our logs! Thanks. - jim savoy - PS We have not applied any of the patches. I read the readme file in the patch directory and none of the fixes seemed to apply to our situation. I am having a weird problem with Radiator 2.16.1 on Solaris 2.6 I am running a split setup using separate Accounting and Authenticating servers. It looks like the auth server stops logging until killed while still doing authentication. The log looks like: Sat Aug 12 22:43:52 2000: DEBUG: Handling with Radius::AuthLDAP2 Sat Aug 12 22:43:52 2000: DEBUG: Connecting to ldap.whepp.nl, port 389 Sun Aug 13 16:41:11 2000: DEBUG: Reading users file /etc/opt/radius/users Sun Aug 13 16:41:13 2000: INFO: Server started: Radiator 2.16.1 If I look at the ldap logs I still see connections coming in on the LDAP server. The accounting server also sees Start and Stop accounting records. I am not using any special naming in the logfile name, just a 'LogDir /var/radius' line. Paul === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging stops while server appears to be still working
Hi James, there were several changes in the LDAP connection handling between 2.13 and 2.16.1, and there is a note in the history file that there is a fix in 2.16.2 for problems with limited file handles which sounds relevant. Suggest you upgrade to the recent 2.16.3. Cheers. On Aug 29, 10:06am, Hugh Irvine wrote: Subject: Re: (RADIATOR) Logging stops while server appears to be still wor Hello James - The log below appears to show that the LDAP server has stopped responding for some reason. I have copied this mail to Mike to see if he has any ideas. regards Hugh At 14:36 -0600 28/8/00, James Savoy wrote: Hello everyone, I am having the same problems that Paul is having. We recently upgraded from Radiator 2.13 on Solaris 2.6 to Radiator 2.16.1 on Solaris 2.7. While we have had no problems at all with authentication, our logging seems to quit on us after just a few hours. The logfile consistently ends with: Fri Aug 11 18:00:12 2000: DEBUG: Handling request with Handler 'Realm=DEFAULT' Fri Aug 11 18:00:12 2000: DEBUG: Rewrote user name to pirnae Fri Aug 11 18:00:12 2000: DEBUG: Deleting session for pirnae, 142.66.14.3, 6 Fri Aug 11 18:00:12 2000: DEBUG: Handling with Radius::AuthLDAP Fri Aug 11 18:00:12 2000: DEBUG: Connecting to deimos.online.uleth.ca, port 389 Where "pirnae" is one of our users (this is always different) and 142.66.14.3 is the IP of one of our modem pools. The machine "deimos" is where our ldap is located. Our radldap.cfg file (without secrets) looks like this: Foreground Trace 4 PidFile /tmp/radiusd.pid AuthPort1645 AcctPort1646 LogDir . DbDir . LogFile %L/radius-user-logfile Client DEFAULT DupInterval 0 /Client Realm DEFAULT RewriteUsername s/^([^@]+).*/$1/ RejectHasReason AuthBy LDAP Hostdeimos.online.uleth.ca Port 389 BaseDN o=University of Lethbridge, c=CA UsernameAttruid PasswordAttrulmodempasswd /AuthBy /Realm Any ideas on what is causing this? Again, we can get by without a fix, but it would be nice to have something in our logs! Thanks. - jim savoy - PS We have not applied any of the patches. I read the readme file in the patch directory and none of the fixes seemed to apply to our situation. I am having a weird problem with Radiator 2.16.1 on Solaris 2.6 I am running a split setup using separate Accounting and Authenticating servers. It looks like the auth server stops logging until killed while still doing authentication. The log looks like: Sat Aug 12 22:43:52 2000: DEBUG: Handling with Radius::AuthLDAP2 Sat Aug 12 22:43:52 2000: DEBUG: Connecting to ldap.whepp.nl, port 389 Sun Aug 13 16:41:11 2000: DEBUG: Reading users file /etc/opt/radius/users Sun Aug 13 16:41:13 2000: INFO: Server started: Radiator 2.16.1 If I look at the ldap logs I still see connections coming in on the LDAP server. The accounting server also sees Start and Stop accounting records. I am not using any special naming in the logfile name, just a 'LogDir /var/radius' line. Paul === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. -- End of excerpt from Hugh Irvine -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging stops while server appears to be still working
Hello Paul - The excerpt of the log file below appears to show that Radiator has crashed and restarted. Could you send me a copy of the configuration file (no secrets) and a more complete trace 4 showing what happens before what you see below? thanks Hugh I am having a weird problem with Radiator 2.16.1 on Solaris 2.6 I am running a split setup using separate Accounting and Authenticating servers. It looks like the auth server stops logging until killed while still doing authentication. The log looks like: Sat Aug 12 22:43:52 2000: DEBUG: Handling with Radius::AuthLDAP2 Sat Aug 12 22:43:52 2000: DEBUG: Connecting to ldap.whepp.nl, port 389 Sun Aug 13 16:41:11 2000: DEBUG: Reading users file /etc/opt/radius/users Sun Aug 13 16:41:13 2000: INFO: Server started: Radiator 2.16.1 If I look at the ldap logs I still see connections coming in on the LDAP server. The accounting server also sees Start and Stop accounting records. I am not using any special naming in the logfile name, just a 'LogDir /var/radius' line. Paul ---End of forwarded mail from [EMAIL PROTECTED] -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging attributes by integer..
Hello Mike -
On Sat, 20 May 2000, Mike Nerone wrote:
When using AcctColumnDef, you can tell Radiator to log a particular
attribute by its integer value, which is what I want to do. Unfortunately,
I'm not using AcctColumnDef, I'm using my own AcctSQLStatement for more
flexibility. Specifically, I'm using the following:
AcctSQLStatement\ insert into
accounting set\mailbox= '%U',
\domain = '%R', \timestamp
= from_unixtime(%{Timestamp}), \statustype =
'%{Acct-Status-Type}', \ipaddress =
'%{Framed-IP-Address}',\inputoctets=
'%{Acct-Input-Octets}',\outputoctets =
'%{Acct-Output-Octets}', \sessionid =
'%{Acct-Session-Id}', \terminatecause =
'%{Acct-Terminate-Cause}', \ascendcause=
'%{Ascend-Disconnect-Cause}', \nasipaddress = '%N',
\nasport= '%{NAS-Port}', \
nasporttype= '%{NAS-Port-Type}',\servicetype=
'%{Service-Type}', \callednumber =
'%{Called-Station-Id}',\callingnumber =
'%{Calling-Station-Id}'
I've omitted the rest of the config...it all works fine. Note that 1)
from_unixtime is a mysql function, so don't go looking for it, and 2) this
"insert into table SET" syntax is not standard SQL, but mysql supports it,
and this syntax works fine.
My question is, how can I make certain attributes (specifically Status-Type,
Terminate-Cause, and Ascend-Disconnect-Cause) log as integers instead of
strings. Is there a corresponding %-substitution that would give me the
integer?
If there's is no such %-substitution, then it occurred to me to use a
PreClientHook to add a pseudo-attribute containing the integer, and then log
that in the SQL statement (or with AcctColumnDef, for that matter), so that
no translation is done, with something like:
$request-changeattr('Acct-Terminate-Cause-Int', \
$request-getAttrByNum($Radius::Radius::ACCT_TERMINATE_CAUSE));
I believe this would work fine for the well-known attributes, but one of the
attributes I want to do this with is vendor-specific
(Ascend-Disconnect-Cause), and being the neophyte perl programmer I am, I
don't see a way to get to the integer information. Come to think of it, i
would PREFER this solution, because I'm then free to massage the data a bit
more and store either Acct-Terminate-Cause or Ascend-Disconnect-Cause in a
single field in the database, since each NAS only sends one or the other. To
tell them apart, I'd add 1000 to the value if its an
Ascend-Disconnect-Cause.
So my question becomes: Within a hook, how do I get the integer value of a
vendor-specific-attribute instead of its string value from the dictionary?
Have a look at this and let me know how you get on:
"goodies/extendedMacros.patch"
This is in the "goodies" directory in the distribution.
There was also a discussion about this same topic on the list about six months
ago from memory - check the archive site and do a search:
http://www.starport.net/~radiator
On the topic of hooks, there is some example code here:
http://www.open.com.au/radiator/downloads/patches-2.15/hooks.txt
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm
Then the simplest thing is to chain together two AuthBy's, the first to log the original username in standard format (an AuthBy FILE with a DEFAULT would do), and the second to do the rewrite and other processing. # configure two AuthBy's with an AuthByPolicy Realm AuthByPolicy ContinueAlways AuthBy FILE Filename %D/default.accounting AcctLogFileName . AuthBy AuthBy RewriteUsername . /AuthBy /Realm That sounds cool, but according the documentation, I can only use AcctLogFileName and RewriteUsername (and friends) inside a Realm/Handler, not inside an AuthBy clause itself... I'll give it a try, but I'm dubious about it working. Andrew === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm
Hello Andrew - On Wed, 10 May 2000, Andrew Pollock wrote: Then the simplest thing is to chain together two AuthBy's, the first to log the original username in standard format (an AuthBy FILE with a DEFAULT would do), and the second to do the rewrite and other processing. # configure two AuthBy's with an AuthByPolicy Realm AuthByPolicy ContinueAlways AuthBy FILE Filename %D/default.accounting AcctLogFileName . AuthBy AuthBy RewriteUsername . /AuthBy /Realm That sounds cool, but according the documentation, I can only use AcctLogFileName and RewriteUsername (and friends) inside a Realm/Handler, not inside an AuthBy clause itself... I'll give it a try, but I'm dubious about it working. Ooops - you are partly right. The AcctLogFileName is intended for a Realm/Handler, but you can have as many RewriteUsername's as you like, and you can use them in an AuthBy GROUP. So - one more try Realm . AcctLogFileName ... AuthBy GROUP RewriteUsername ... AuthBy . . /AuthBy /AuthBy /Realm Sorry about the confusion. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm
-Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 10 May 2000 4:36 PM To: Andrew Pollock; [EMAIL PROTECTED] Subject: RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm Hello Andrew - On Wed, 10 May 2000, Andrew Pollock wrote: Then the simplest thing is to chain together two AuthBy's, the first to log the original username in standard format (an AuthBy FILE with a DEFAULT would do), and the second to do the rewrite and other processing. # configure two AuthBy's with an AuthByPolicy Realm AuthByPolicy ContinueAlways AuthBy FILE Filename %D/default.accounting AcctLogFileName . AuthBy AuthBy RewriteUsername . /AuthBy /Realm That sounds cool, but according the documentation, I can only use AcctLogFileName and RewriteUsername (and friends) inside a Realm/Handler, not inside an AuthBy clause itself... I'll give it a try, but I'm dubious about it working. Ooops - you are partly right. The AcctLogFileName is intended for a Realm/Handler, but you can have as many RewriteUsername's as you like, and you can use them in an AuthBy GROUP. So - one more try Realm . AcctLogFileName ... AuthBy GROUP RewriteUsername ... AuthBy . . /AuthBy /AuthBy /Realm Sorry about the confusion. That's okay. That also worked a treat. Thanks very much. Andrew === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm
-Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 10 May 2000 12:24 PM To: Andrew Pollock; [EMAIL PROTECTED] Subject: Re: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm Hello Andrew - On Wed, 10 May 2000, Andrew Pollock wrote: Hi guys, Is it possible to log accounting records locally in an unmodified form, then strip off the realm before proxying the accounting records to another server? I want the realm in the local detail file but I don't want the realm in the accounting record I forward to the other server. Yes. You can use the AcctLogFileName and AcctLogFileFormat parameters in your realm(s) and specify one of the "%" special characters to log (probably "%u"). Have a look at sections 6.2, 6.13.4 and 6.13.5 in the Radiator 2.15 reference manual. Correct me if I'm wrong, but by using AcctLogFileFormat, don't I lose the standard RADIUS format of the detail file? I want a standard format detail file, I just want it to log the User-Name unmodified, so I basically want it to log %u for the User-Name instead of %U Andrew === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to 2 accounting dbs
On Fri, 17 Mar 2000, Hugh Irvine wrote: I was wondering if there is a way to make radiator send accounting info to two different dbs. I'm using AuthBy Rodopi and the accounting attributes recorded are minimal. I'd like to be able to log more information to another sql db at the same time. Is this possible? Sure - chain two AuthBy's like this: This just gave me an idea. First, what happens if a single request is handled by more than 1 AuthBy ...'s resulting in some mix of accepts and rejects? Would the first returned result win and be the only one returned to the client? We have problems on our Cisco access servers when an AuthBy RADIUS request times out because the radius server it was proxied to is unreachable or not responding. We thought about trying to hack radiator to return a reject in these cases...but what happens with AuthByPolicy ContinueWhileIgnore if multipel AuthBy ...'s fork, and one returns a non Ignore result while the other is still running? Is the remaining AuthBy ... killed? I was thinking "what if we did an AuthBy External that just slept for X seconds and returned a reject?" Doing this for every login would result in too many radiusd processes sitting around unless they were killed off when the first AuthBy RADIUS returned a non-ignore result. I think it's getting too late at night for rational thought though. Can timeout() in AuthRADIUS.pm return ($main::REJECT) to fake a reject packet? -- Jon Lewis *[EMAIL PROTECTED]*| Spammers will be winnuked or System Administrator| nestea'd...whatever it takes Atlantic Net| to get the job done. _http://www.lewis.org/~jlewis/pgp for PGP public key__ === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to 2 accounting dbs
Hello John - On Fri, 17 Mar 2000, [EMAIL PROTECTED] wrote: On Fri, 17 Mar 2000, Hugh Irvine wrote: I was wondering if there is a way to make radiator send accounting info to two different dbs. I'm using AuthBy Rodopi and the accounting attributes recorded are minimal. I'd like to be able to log more information to another sql db at the same time. Is this possible? Sure - chain two AuthBy's like this: This just gave me an idea. First, what happens if a single request is handled by more than 1 AuthBy ...'s resulting in some mix of accepts and rejects? Would the first returned result win and be the only one returned to the client? Exactly what happens is determined by the AuthByPolicy used to chain the AuthBy ...'s. There will only be one reply returned to the Client however, except with AuthBy RADIUS which continues processing asynchronously. We have problems on our Cisco access servers when an AuthBy RADIUS request times out because the radius server it was proxied to is unreachable or not responding. We thought about trying to hack radiator to return a reject in these cases...but what happens with AuthByPolicy ContinueWhileIgnore if multipel AuthBy ...'s fork, and one returns a non Ignore result while the other is still running? Is the remaining AuthBy ... killed? I was thinking "what if we did an AuthBy External that jjust slept for X seconds and returned a reject?" Doing this for every login would result in too many radiusd processes sitting around unless they were killed off when the first AuthBy RADIUS returned a non-ignore result. The thought with AuthBy RADIUS is that it is better to Ignore if a proxy is unreachable, because then the NAS can walk through a list of alternative Radius servers. If you return a Reject, of course, the NAS will simply Reject the call. Also, from your description above, it does not make sense to chain AuthBy's and then specify Fork, as the two concepts are mutually exclusive. Ie - you can't chain AuthBy ...'s that depend on returned results before moving to the next one, and then not wait for the result. I think it's getting too late at night for rational thought though. Can timeout() in AuthRADIUS.pm return ($main::REJECT) to fake a reject packet? You could probably achieve the same result by not specifying a retry count on the NAS, or possibly a relatively short timeout and only one retry. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to 2 accounting dbs
Hello Chris - On Fri, 17 Mar 2000, CAH wrote: Hey all, I was wondering if there is a way to make radiator send accounting info to two different dbs. I'm using AuthBy Rodopi and the accounting attributes recorded are minimal. I'd like to be able to log more information to another sql db at the same time. Is this possible? Sure - chain two AuthBy's like this: Handler or Realm AuthByPolicy ContinueAlways AuthBy SQL DBSource DBUsername DBAuth AuthSelect AccountingTable ACCOUNTING AcctColumnDef . /AuthBy AuthBy RODOPI /AuthBy /Handler or /Realm Note the empty AuthSelect in the AuthBy SQL to stop authentication. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging turned on
I too have this problem but everything works except for the information going to stdout. I've even got it authenticating the way I need it so I just ignored it. Would be nice to know why it didn't work. I'm running on FreeBSD 3.3 stable and the latest Radiator(without any patches) On Tue, 30 Nov 1999, Hugh Irvine wrote: Hello Dave - On Tue, 30 Nov 1999, Dave Kitabjian wrote: See: http://www.open.com.au/radiator/install.html It says: "Run radiator with perl radiusd -config_file goodies/simple.cfg. This runs Radiator with logging turned on (so you can see whats happening), and authenticates all requests from the file users. You will see some messages, followed by INFO: Server started. Radiator is now waiting for requests to arrive." However, I get *no* messages at all either to the console or the local terminal. - I'm using the stock "simple.cfg", which has "LogStdout" - All "make test" tests passed "ok" - The authentication test succeeds regardless: web# perl radpwtst -user fred -password fred sending Access-Request... OK sending Accounting-Request Start... OK sending Accounting-Request Stop... OK - "detail" contains accounting records Could you tell me what platform you are running on? and which version of Radiator? thanks Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) logging turned on
Here is the platform: web# uname -a FreeBSD ... 3.2-STABLE FreeBSD 3.2-STABLE #0: Mon Jul 12 08:55:0 5 EDT 1999 root@...:/usr/src/sys/compile/WEB i386 Regarding version, I downloaded: "Radiator-2.14.1"; no patches were applied. (btw, is there a way to confirm the version from the command line, such as "perl radiusd -v"?) Let me know what else I can do to assist. Dave -Original Message- From: Hugh Irvine [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, November 30, 1999 1:00 AM To: [EMAIL PROTECTED]; Dave Kitabjian; [EMAIL PROTECTED] Subject: Re: (RADIATOR) "logging turned on" Hello Dave - On Tue, 30 Nov 1999, Dave Kitabjian wrote: See: http://www.open.com.au/radiator/install.html It says: "Run radiator with perl radiusd -config_file goodies/simple.cfg. This runs Radiator with logging turned on (so you can see whats happening), and authenticates all requests from the file users. You will see some messages, followed by INFO: Server started. Radiator is now waiting for requests to arrive." However, I get *no* messages at all either to the console or the local terminal. - I'm using the stock "simple.cfg", which has "LogStdout" - All "make test" tests passed "ok" - The authentication test succeeds regardless: web# perl radpwtst -user fred -password fred sending Access-Request... OK sending Accounting-Request Start... OK sending Accounting-Request Stop... OK - "detail" contains accounting records Could you tell me what platform you are running on? and which version of Radiator? thanks Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging turned on
Hello Dave - On Tue, 30 Nov 1999, Dave Kitabjian wrote: See: http://www.open.com.au/radiator/install.html It says: "Run radiator with perl radiusd -config_file goodies/simple.cfg. This runs Radiator with logging turned on (so you can see whats happening), and authenticates all requests from the file users. You will see some messages, followed by INFO: Server started. Radiator is now waiting for requests to arrive." However, I get *no* messages at all either to the console or the local terminal. - I'm using the stock "simple.cfg", which has "LogStdout" - All "make test" tests passed "ok" - The authentication test succeeds regardless: web# perl radpwtst -user fred -password fred sending Access-Request... OK sending Accounting-Request Start... OK sending Accounting-Request Stop... OK - "detail" contains accounting records Could you tell me what platform you are running on? and which version of Radiator? thanks Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging incoming requests
David Lloyd writes: On Thu, 11 Nov 1999, Jason J. Horton wrote: We have an ancient radius server that auths via the unix password file, and we want to move those users to our radiator system. To make it interesting, we want to have the passwords in cleartext instead of crypted passwords. Is there any way we can configure Radiator to log an incoming radius request to a flatfile or SQL, say storing username and password (assuming both come thru in cleartext)? This way we can take the entries and dump em into our subscribers table? Radiator already has this facility. It is called PasswordLogFile I believe. It's great for troubleshooting connections, you can tell a customer when they're typing in their password in all caps or something like that. :-) The only problem with PasswordLogFile is that it doesn't catch instances where the username was mistyped. I haven't had a chance to look at that portion of the code yet to see if it can be added, but it is certainly something that I wished was there. Looking back at our records (which go back to Dec 1995), about 85% of all failed logins are due to invalid username/password. The other 15% of failed logins are due to the account being turned off because of unpayed bills or extended non-use (we only charge them what they use, not by a montly flat rate like most ISP's). It becomes more difficult to tell what distribution is bad username vs bad password in our old system, since I didn't distinguish between the two and only logged "Invalid Username/Password" to the log file. However, it does look like about a third of the failed logins were bad usernames, and the other two thirds were for failed passwords. The point I am generally making is that from a support standpoint, they need to see all rejected authentication attempts, not just the ones that had good usernames and bad passwords. Since I wrote my own authentication module, I implemented my own rejected log that does just this. However, I did it a bit differently. Basically, all failed authentication attempts get logged to a reject log using the same format that the accounting log files are written in (ATTRIB=VALUE). This allows me to catch other aspects of the failed calls, such as their phone numbers, whether they are using ASYNC or ISDN, etc. Anyways, that is my 2 cents worth. Scott -- +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineermailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ CNS, HDL Center, Suite 301, Ohio University, Athens, OH 45701-2979 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging incoming requests
Is there any way we can configure Radiator to log an incoming radius request to a flatfile or SQL, say storing username and password (assuming both come thru in cleartext)? PasswordLogFileName passlog.%d%m%Y.txt. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging incoming requests
On Thu, 11 Nov 1999 21:07:12 +, Stuart Henderson wrote: Is there any way we can configure Radiator to log an incoming radius request to a flatfile or SQL, say storing username and password (assuming both come thru in cleartext)? PasswordLogFileName passlog.%d%m%Y.txt. === Is there a way of adding calling-station-id to this file as well ?? Gary --- Ausmail Your virtual home on the net. Email, News Home pages. --- Coming soon !! === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging incoming requests
On Fri, 12 Nov 1999, Gary wrote: On Thu, 11 Nov 1999 21:07:12 +, Stuart Henderson wrote: Is there any way we can configure Radiator to log an incoming radius request to a flatfile or SQL, say storing username and password (assuming both come thru in cleartext)? PasswordLogFileName passlog.%d%m%Y.txt. === Is there a way of adding calling-station-id to this file as well ?? You would have to write a hook to do this (PreClientHook, PreHandlerHook, PreAuthHook or PostAuthHook). hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging connect rates
Thank you very much. This sounds like a perfect approach.
Hugh Irvine wrote:
Hello David -
On Fri, 08 Oct 1999, David Lloyd wrote:
We have three different types of NAS (Livingston, USR, and Ascend). I
would like to be able to log the connection rates in my custom radius
detail file in a consistant manner.
While it is possible to get the connection rates from all three boxes,
they unfortunately each have a different attribute name and number for
where they put the darn thing.
I see this as a good argument for being allowed to specify a different
dictionary for each NAS. I envision a scenario in which I could give the
attributes the same name, for instance:
(In the usr dictionary file)
ATTRIBUTE Connect-Transmit-Rate 0x006A Integer
(In the ascend dictionary file)
ATTRIBUTE Connect-Transmit-Rate 255 Integer
(In the livingston dictionary file)
ATTRIBUTE Connect-Transmit-Rate 1007 Integer
...Then I could just specify %{Connect-Transmit-Rate} in my
AAcctLogFileFormat directive, and be guaranteed to get the right numbers!
The topic of per-client dictionaries has come up previously, but we are still
considering whether or not to implement this as it complicates packet
processing considerably.
I have also just responded to Clement ([EMAIL PROTECTED]) on a related issue.
If you use AuthBy SQL (even just for accounting) you can have multiple
definitions for the same column name:
The simplest and easiest way to do this is with multiple definitions:
AcctColumnDeftransmit_speed,Annex-Transmit-Speed,integer
AcctColumnDeftransmit_speed,Acc-Connect-Tx-Speed,integer
AcctColumnDeftransmit_speed,Some-Other-Transmit-Speed,integer
Only the attribute that is actually present in the packet will be written to
the database, so different NAS-specific information will be written.
This was a new feature in Radiator 2.14, although the manual does not describe
the improved behaviour.
From http://www.open.com.au/radiator/history.html:
In AuthBy SQL, you can now have multiple definition of the same column name in
AcctColumnDef. This allows you to save different attributes from different
types of NAS into the same column in a mixed NAS environment.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Regards
Clement
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging everything with sql into database
some misunderstandings occurred. i already solved the problem, but it
may be useful for others also. for the result i need my database look like
this:
SQL select * from radius_tbl;
ID KEY VALUE
---
1 User-Nameragnar
1 Service-Type Framed-User
1 NAS-IP-Address 203.63.154.1
1 NAS-Port 1234
1 NAS-Port-TypeAsync
1 Acct-Session-Id 1234
1 Acct-Status-Type Start
1 Timestamp936347798
2 User-Nameragnar
2 Service-Type Framed-User
2 NAS-IP-Address 203.63.154.1
2 NAS-Port 1234
2 NAS-Port-TypeAsync
2 Acct-Session-Id 1234
2 Acct-Status-Type Stop
2 Acct-Delay-Time 1
2 Acct-Session-Time1
2 Acct-Input-Octets2
2 Acct-Output-Octets 3
2 Timestamp936347799
20 rows selected.
SQL
as i understood, it is not possible trivially. radiator did need slight
patching. my configuration file finally contains following section:
AuthBy SQL
AuthSelect
DBSource dbi:Oracle:MY_DATABASE_SID
DBUsername ragnar
DBAuth
AcctSQLFormat sub { \
my( $p ) = @_; \
my $str = join "", map { \
my( $key, $value ) = @$_; \
$key =~ s/([^a-zA-Z0-9])/sprintf("%%%d%%",ord($1))/ego; \
$value =~ s/([^a-zA-Z0-9])/sprintf("%%%d%%",ord($1))/ego; \
"$key=$value;"; \
} @{$p-{Attributes}}; \
"begin radius.log('$str'); end;"; \
}
/Auth
as you see i use AcctSQLFormat option. it just returns appropriate sql
statement, which will be executed by radiator.
this example constructs sql function which will be executed by database.
function takes one string as an argument. string is made up from encoded
key-value pairs.
see attatchment for patch. i use radiator version 2.13.1 so the patch is
also for it.
as this logs huge amount of data into database it requires a lot database
tuning.
i have not heavily tested this, but my first attempts were successful.
so it may contain bugs.
ragnar
Radiator already provides funtionality to log everything to
an SQL database. There's no hacking required.
Look at the AuthBy SQL and the Log SQL directives.
The docs are at http://www.open.com.au/radiator/ref.html
I've even posted an example implementation to log accounting
packets into an SQL database while retaining authentication
using another method. Search the mailing list archives.
i'm trying to make radiator to log everything into my database.
my database table would contain following fields: id, key, value.
one log event would be grouped by id. how can this be achieved?
nearest solution i can think of is following:
* hack radiator to provide a perl code to access all event attributes
* encode them into a long string
* call database procedure and pass the string
* the procedure would decode the string and insert key-value pairs
with shared id into table
is there more elegant way to do this? especially should i hack radiator or
does it provide facilities to satisfy my needs without hacking one?
*** AuthSQL.pm.orig Thu Sep 2 14:47:50 1999
--- AuthSQL.pm Thu Sep 2 15:27:01 1999
***
*** 100,105
--- 100,112
{
push(@{$self-{AcctSQLStatement}}, $value);
}
+ elsif ($keyword eq 'AcctSQLFormat')
+ {
+ $self-{AcctSQLFormat} = eval($value);
+ main::log($main::LOG_ERR,
+ "Compilation error in AcctSQLFormat(): $@")
+ if $@;
+ }
else
{
# Multiple inheritance
***
*** 147,153
return ($main::ACCEPT)
if (!defined $self-{AcctColumnDef}
|| $self-{AccountingTable} eq '')
!!defined $self-{AcctSQLStatement};
# If AccountingStartsOnly is set, only process Starts
# Acknowledge and drop anything else
--- 154,161
return ($main::ACCEPT)
if (!defined $self-{AcctColumnDef}
|| $self-{AccountingTable} eq '')
!!defined $self-{AcctSQLStatement}
!!defined $self-{AcctSQLFormat};
# If AccountingStartsOnly is set, only process Starts
# Acknowledge and drop anything else
***
*** 163,168
--- 171,187
$p-getAttrByNum($Radius::Radius::ACCT_STATUS_TYPE)
ne 'Stop';
+ # If AcctSQLFormat is set, execute it.
+ if(defined $self-{AcctSQLFormat})
+ {
+ # We use an eval so an error in the hook wont kill us.
+ my $sql = eval{ {$self-{AcctSQLFormat}}($p); };
+ main::log( $main::LOG_ERR, "Error in AcctSQLFormat(): $@" )
+ if $@;
+ defined($sql)
+
Re: (RADIATOR) logging everything with sql into database
Radiator already provides funtionality to log everything to an SQL database. There's no hacking required. Look at the AuthBy SQL and the Log SQL directives. The docs are at http://www.open.com.au/radiator/ref.html I've even posted an example implementation to log accounting packets into an SQL database while retaining authentication using another method. Search the mailing list archives. At 02:29 PM 9/2/99 +0300, Ragnar Kurm wrote: i'm trying to make radiator to log everything into my database. my database table would contain following fields: id, key, value. one log event would be grouped by id. how can this be achieved? nearest solution i can think of is following: * hack radiator to provide a perl code to access all event attributes * encode them into a long string * call database procedure and pass the string * the procedure would decode the string and insert key-value pairs with shared id into table is there more elegant way to do this? especially should i hack radiator or does it provide facilities to satisfy my needs without hacking one? ragnar === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging everything with sql into database
Hello Ragnar - On Thu, 02 Sep 1999, Ragnar Kurm wrote: i'm trying to make radiator to log everything into my database. my database table would contain following fields: id, key, value. one log event would be grouped by id. how can this be achieved? nearest solution i can think of is following: * hack radiator to provide a perl code to access all event attributes * encode them into a long string * call database procedure and pass the string * the procedure would decode the string and insert key-value pairs with shared id into table is there more elegant way to do this? especially should i hack radiator or does it provide facilities to satisfy my needs without hacking one? Yes there is: Log SQL DBSource ... DBUsername ... DBAuth ... ... /Log or # Use an SQL table specified by AccountingTable # Columns are defined by AcctColumnDef AuthBy SQL DBSource ... DBUsername ... DBAuth ... AccountingTable ... AcctColumnDef ... ... /AuthBy or # Use an SQL table specified by AccountingTable # Define an SQL statement to perform inserts with AcctSQLStatement AuthBy SQL DBSource ... DBUsername ... DBAuth ... AccountingTable ... AcctSQLStatement ... /AuthBy There are a number of excellent examples in the distributed goodies directory. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Neale Banks wrote: On Sat, 7 Aug 1999, Hugh Irvine wrote: [...] I would suggest something like this: Realm foo.bar # Force all clauses to be executed AuthByPolicy ContinueAlways # Do our normal processing AuthBy .. /AuthBy # Set up a proxy for Accounting only AuthBy RADIUS Host Secret NoForwardAuthentication /AuthBy # Log accounting to local file AcctLogFileName filename /Realm Thanks Hugh, this looks likely. Is there something else we can/should add to tell Radiator not to worry if the other host doesn't ACK the accounting packets? I experienced some troubles with the suggested configuration. If you use NoForwardAuthentication RADIUS Authentication-Requests are not forwarded but ACCEPTED. I noticed that if the first AuthBy failed the user would be granted access anyway because of the second AuthBy. Accounting was taken care of exactly as I wanted. But this was not true for Authentication ;-) Currently I am using Handler statements as discussed on this list to make a copy of accounting information without granting everybody access. -Wim === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Neale Banks wrote: Thanks for that - ACCEPTing everybody is definitely not what we want 8-O What's the trick to doing this with a Handler? I used to make a copy of all accounting by simply running "Trace 4". But now that I am monitoring radiusd with MRTG my logging really exploded. So I wanted to make a copy of all Stop-record without using "Trace 4". The configuration which works for me looks like this: # Handler matches only Stop-records for realm *.foo.bar Handler Acct-Status-Type=Stop,Realm=/^(.*\.)*foo\.bar$/i AuthByPolicy ContinueAlways AuthBy RADIUS .. /AuthBy AuthBy RADIUS .. /AuthBy /Handler # lots of the same handlers for different foo.bar's # Handler matches all records for realm *.foo.bar # but Stop-records were taken care of above. Handler Realm=/^(.*\.)*foo\.bar$/i AuthBy RADIUS .. /AuthBy /Handler # lots of the same handlers for different foo.bar's You could replace Stop by a regular expression if you also would like to have a copy of all Start records. And be carefull if you mix Realm and Handler statements. Sometimes mixing both of them doesn't work. -Wim === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
Hi Neale - On Sat, 07 Aug 1999, Neale Banks wrote: On Sat, 7 Aug 1999, Wim Biemolt wrote: I experienced some troubles with the suggested configuration. If you use NoForwardAuthentication RADIUS Authentication-Requests are not forwarded but ACCEPTED. I noticed that if the first AuthBy failed the user would be granted access anyway because of the second AuthBy. Accounting was taken care of exactly as I wanted. But this was not true for Authentication ;-) Currently I am using Handler statements as discussed on this list to make a copy of accounting information without granting everybody access. Thanks for that - ACCEPTing everybody is definitely not what we want 8-O I realised after I sent this that I had put the clauses around the wrong way. What I should have said was this: Realm foo.bar # Force all clauses to be executed AuthByPolicy ContinueAlways # Set up a proxy for Accounting only AuthBy RADIUS Host Secret NoForwardAuthentication /AuthBy # Do our normal processing AuthBy .. /AuthBy # Log accounting to local file AcctLogFileName filename /Realm In this case the Accounting packets will be forwarded to the proxy and the Authentication packets will be accepted. The following AuthBy will either accept or reject normally. What's the trick to doing this with a Handler? Realms are just special cases of Handlers. There is no difference other than Realms look for an exact match on a realm and then stop processing, while all Handlers are executed in configuration file sequence and can match on any attribute(s). Realm foo.bar is equivalent to Handler Realm=foo.bar Note that you should not mix Realms and Handlers in the same configuration (because of the conflicting continuation behaviour described above), so you could also do something like this: # Handler for Realm=foo.bar Handler Realm=foo.bar # Do our normal processing AuthBy .. /AuthBy # Log accounting to local file AcctLogFileName filename /Handler # Additional Handler for Accounting packets only Handler Acct-Status-Type=/.+/ # Set up a proxy for accounting AuthBy RADIUS Host Secret /AuthBy /Handler In both cases above, two Accounting-Accept packets will be retutned to the Clinet NAS. And to answer Neale's other question about AuthBy RADIUS - the retry behaviour can be modified with the "Retries" and "RetryTimeout" parameters (Section 6.25 in the 2.14.1 manual). hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging failed entries?
On Fri, 06 Aug 1999, Bill wrote: I'm having a little trouble getting our logging the way I want it. Our current (merit) radius logs to a file entries like this: Thu Aug 5 11:29:41 1999: rad_authenticate: 125/136 'username' at 204.228.159.2 PPP Thu Aug 5 11:29:42 1999: Authentication: 125/136 'username' via 204.228.159.2 from 204.228.159.2 por Thu Aug 5 11:29:42 1999: Accounting: 154/19 'username' via 198.60.22.110 from 204.228.159.2 port 521 Start - OK this is a normal Start entry, a failed auth attempt looks like: Thu Aug 5 11:36:34 1999: Authentication: 248/147 'username' via 166.70.1.41 from 166.70.1.41 port 18 PPP - FAILED Authentication failure With Radiator the only method I can find with Log FILE, which logs information that would go into the detail logs, which as far as I can tell, doesn't include failed authentication attempts. Is there a way to log these failed auth attempts? It'd be nice to also have the option of logging what was entered as the password for failed auths. (only for failed auths, not for successfull auths too). This is pretty much the last thing I need to fix before we can switch over to Radiator full-time, Any pointers would be much appreciated. I think you have two options here. The first is to use the PasswordLogFileName in you Handlers (see Section 6.13.7 in the 2.14.1 Reference manual). The second is to use Log SQL and tailor it exactly to your needs. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) logging failed entries?
-Original Message- From: Bill [mailto:[EMAIL PROTECTED]] Is there a way to log these failed auth attempts? It'd be nice to also have the option of logging what was entered as the password for failed auths. (only for failed auths, not for successfull auths too). There is a security issue with this; some of the failed attempts will be typos from the legitimate user, so the password will be "almost" correct. Which means that the logfile is as sensitive info as the password file. This might not be a problem for you, but in many cases it is. /Ingvar Ericsson Radio Systems AB Center for Wireless Internet Integration P.O. Box 1885, Teknikringen 8, S-581 17 Linköping, Sweden Phone +46 13 32 22 87 Mobile +46 70 321 3395 Fax +46 70 617 3395 mailto: [EMAIL PROTECTED] ÿ Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging
Hi Michael, On May 10, 5:31pm, Michael wrote: Subject: (RADIATOR) Logging Hi, With Radiator logging at Trace 3 would it be possible to modify something to have the Calling-Station-Id log along with the error? Which error are you thinking of? In general, the only way to alter whats logged in a log message is to alter the code, or to create a new logging class (ie a new subclass of LogGeneric). Itsd very easy to do, but it still comes down to modifying the code. Cheers. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging
Hi Stephen, On Mar 31, 2:20pm, Stephen Roderick wrote: Subject: (RADIATOR) Logging Are there any plans to improve the logging options? I would really like to be able to log different types of info in different files. i.e. debugging, errors, etc. Which of course would then lead to a request for increased granularity in the types. :-) Well, we didnt have any further plans in this area until we heard from you! Im sure you know that you can set a cutoff to the logging level by using the Trace parameter, but we currently have no plans for any other way to select the types of messages to be logged. But, if there is demand for it, we can add it. Anyone else feel that this is very desirable? -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, external, etc etc on Unix, Win95/8, NT, Rhapsody === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
