(RADIATOR) How do you log proxy auth packets in a SQL dB or file?

[Hugh Irvine]

Hello Mary Grace -

What you describe sounds like a session database.

You should add something like this to the end of your configuration 
file:

<SessionDatabase SQL>
	DBSource dbi:mysql:radius:1.2.3.4:3306
	DBUsername foobar
	DBAuth raboof
</SessionDatabase.

See section 6.7 in the Radiator 3.6 reference manual.

regards

Hugh


On Sunday, Aug 3, 2003, at 08:51 Australia/Melbourne, Mary Grace wrote:

> Hi everyone!
>
> We have a standard proxy radius setup going that successfully stores 
> accounting data received from an upstream radius server in our server 
> using AuthBy SQL, while proxying using AuthBy RADIUS the Auth requests 
> to a downstream RADIUS server.  The downstream then does the Auth, 
> sends back up through us the ACCEPT and keeps its own copy of the 
> Accounting info, and we proxy the ACCEPT packets back up to our 
> upstream's radius.
>
> The question has arisen as to how we can log or keep a copy also of 
> the upstream's Auth REQUEST packet info that we proxy down to our 
> downstream's radius server.  We would prefer to store it in a SQL 
> table using something like AcctColumnDefs, or at least in a password 
> log format and detail log format showing the actual Auth Req and Auth 
> Response packets that flow up and down through us from the upstream 
> radius to our downstream radius.
>
> The reason to do this is of course to have a basis for using SQL to 
> correct for false simultaneous login denials when a STOP packet gets 
> lost and a user who calls in (from the same Calling-Station ID as the 
> Calling-Station ID he is "currently" (due to the missed STOP packet) 
> assumed to be logged in to) is desired to be authenticated anyway.  
> One could detect such a condition, delete the prior session, and then 
> let him in directly with a hook.
>
> But, I don't know how to tell if that user with a live current START 
> record in our Accounting dB is asking to Auth again unless I can get 
> and store a copy of that second Auth Req packet, not just a new start 
> record that I will never see...... :-(
>
> Thanks in advance,
>
> Mary Grace
>
> *****************************************************************
> Foreground
> LogStdout
> Trace	5
> PidFile	C:radius\radiusd.pid
> BindAddress 1-2-3-4
> AuthPort	1645
> AcctPort	1646
> LogDir C:\radius\radlogs
> DbDir	C:\radius
> LogFile		%L/logfile-1-2-3-4-%Y%m%d.log
> DictionaryFile %D/dictionary
> <Client 4.3.2.1>
> 	Secret shhh!
> </Client>
> <Client 4.3.2.2>
> 	Secret shhh!
> </Client>
> <Realm test.net>
> RewriteUsername	tr/[A-Z]/[a-z]/
> AcctLogFileName	%L/detail-4-test%Y%m%d.log
> PasswordLogFileName %L/password-4-test%Y%m%d.log
> AuthByPolicy ContinueAlways
> <AuthBy SQL>
> DBSource dbi:mysql:radius:1.2.3.4:3306
> DBUsername foobar
> DBAuth raboof
> AuthSelect
> #AuthSelect select PASSWORD, CHECKATTR, REPLYATTR from 
> SUBSCRIBERS_TEST_NET
> # where USERNAME=%0
> #AuthColumnDef 0,Password,check
> #AuthColumnDef 1,GENERIC,check
> #AuthColumnDef 2,GENERIC,reply
> AccountingTable accttestnet%Y%m
> AcctColumnDef user_name,User-Name
> AcctColumnDef nas_ip_address,NAS-IP-Address
> AcctColumnDef nas_port,NAS-Port
> AcctColumnDef service_type,Service-Type
> AcctColumnDef framed_protocol,Framed-Protocol
> AcctColumnDef framed_ip_address,Framed-IP-Address
> AcctColumnDef class,Class
> AcctColumnDef called_station_id,Called-Station-Id
> AcctColumnDef calling_station_id,Calling-Station-Id
> AcctColumnDef acct_status_type,Acct-Status-Type
> AcctColumnDef acct_delay_time,Acct-Delay-Time
> AcctColumnDef acct_input_octets,Acct-Input-Octets
> AcctColumnDef acct_output_octets,Acct-Output-Octets
> AcctColumnDef acct_session_id,Acct-Session-Id
> AcctColumnDef acct_authentic,Acct-Authentic
> AcctColumnDef acct_session_time,Acct-Session-Time,integer
> #AcctColumnDef start_time,%b-%0{Acct-Session-Time},literal
> AcctColumnDef acct_input_packets,Acct-Input-Packets
> AcctColumnDef acct_output_packets,Acct-Output-Packets
> AcctColumnDef acct_terminate_cause,Acct-Terminate-Cause
> AcctColumnDef event_timestamp,Event-Timestamp,integer
> AcctColumnDef nas_port_type,NAS-Port-Type
> AcctColumnDef connect_info,Connect-Info
> AcctColumnDef ascend_pre_input_octets,Ascend-Pre-Input-Octets
> AcctColumnDef ascend_pre_output_octets,Ascend-Pre-Output-Octets
> AcctColumnDef ascend_pre_input_packets,Ascend-Pre-Input-Packets
> AcctColumnDef ascend_pre_output_packets,Ascend-Pre-Output-Packets
> AcctColumnDef ascend_disconnect_cause,Ascend-Disconnect-Cause
> AcctColumnDef ascend_connect_progress,Ascend-Connect-Progress
> AcctColumnDef ascend_data_rate,Ascend-Data-Rate
> AcctColumnDef ascend_presession_time,Ascend-PreSession-Time,integer
> AcctColumnDef ascend_xmit_rate,Ascend-Xmit-Rate
> AcctColumnDef timestamp,Timestamp,integer
> </AuthBy>
> <AuthBy RADIUS>
> Host 4.3.2.3
> Secret shhh!
> AuthPort 1645
> AcctPort 1646
> </AuthBy>
> </Realm>
> <Log FILE>
> Filename %L/backuplog4-3-2-1-%Y%m%d.log
> Trace 5
> </Log>
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

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

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.