(RADIATOR) Proxying accounting requests.

Hugh Irvine hugh at open.com.au
Fri May 24 20:32:58 CDT 2002


Hello -

If you just want to proxy the radius requests, you would use the AuthBy 
RADIUS clause.

regards

Hugh


On Sat, 25 May 2002 05:33, Sysadmin wrote:
> I can't do it with sql, because I'm still trying to get that to work
> between the two servers :(  That was the part that was getting me.  Is
> there a way to do it with AuthBy Proxy or something that does not have to
> interface with a db directly.  If I succeed with freetds or DBD-Proxy,
> then I'll be in good shape (your example makes perfect sense), but so far
> it is failing.
>
> Comments on my other post:
>    I did a truss again radiusd while doing authby platypus and found that
> freetds is dumping on the debug file for some reason.  Still trying to
> figure out why.
>
> Thanks for all your help.
>
> On Sat, 25 May 2002, Hugh Irvine wrote:
> > Hello -
> >
> > As mentioned in my previous mail, the example I provided does exactly
> > what you require. Is there something that is not clear that I can clarify
> > for you?
> >
> > regards
> >
> > Hugh
> >
> > On Fri, 24 May 2002 23:19, Sysadmin wrote:
> > > Hi,
> > > This is kind of weird, but here goes.
> > >   I have a NAS that is under the control of a partner company.  They
> > > forward all authentication to my radius servers. I now have a customer
> > > that is user their NAS, but did not want to move his radius
> > > username/passwd db to my server, so I have to proxy all the requests to
> > > his radius server. I'm interested in monitoring their usage and so are
> > > they.
> > >   So I need to be able to log the start/stop accounting packet for
> > > their realm to my accounting database and also fwd it onto their
> > > accounting database.  Both accounting servers are running cisco's ACS
> > > radius, so they accept the stop/start packets on port 1646 and then
> > > store them in sql. The reason for not just doing the one central server
> > > is because the partner company wants to make sure we are not over
> > > billing them.  :(
> > >
> > > Thanks for you help.
> > >
> > > On Fri, 24 May 2002, Hugh Irvine wrote:
> > > > Hello -
> > > >
> > > > I don't understand your question, sorry.
> > > >
> > > > Could you explain the requirement in a bit more detail?
> > > >
> > > > thanks
> > > >
> > > > Hugh
> > > >
> > > > On Fri, 24 May 2002 00:53, Sysadmin wrote:
> > > > > Hi,
> > > > >  In this case I am not using sql at the central accounting server
> > > > > or at the host I am proxying to.  So is there a way for me to fwd
> > > > > accounting request to both hosts on port 1646?
> > > > >
> > > > > Thanks
> > > > >
> > > > > -----Original Message-----
> > > > > From: Hugh Irvine [mailto:hugh at open.com.au]
> > > > > Sent: Monday, May 13, 2002 7:09 PM
> > > > > To: sysadmin at bigbrain.net; radiator at open.com.au
> > > > > Subject: Re: (RADIATOR) Proxying accounting requests.
> > > > >
> > > > >
> > > > >
> > > > > Hello -
> > > > >
> > > > > You will need to add an AuthBy SQL clause to your configuration
> > > > > file.
> > > > >
> > > > > Something like this:
> > > > >
> > > > > # define AuthBy SQL clause for accounting
> > > > >
> > > > > <AuthBy SQL>
> > > > > 	Identifier SQLAccounting
> > > > > 	......
> > > > > 	# empty AuthSelect to disable authentication
> > > > > 	AuthSelect
> > > > >
> > > > > 	# define accounting
> > > > > 	AccountingTable ACCOUNTING
> > > > > 	AcctColumnDef .....
> > > > > 	.....
> > > > > </AuthBy>
> > > > >
> > > > > # define Realms
> > > > >
> > > > > <Realm some.realm>
> > > > > 	AuthByPolicy ContinueAlways
> > > > > 	AuthBy SQLAccounting
> > > > > 	<AuthBy ....>
> > > > > 		....
> > > > > 	</AuthBy>
> > > > > 	.....
> > > > > </Realm>
> > > > >
> > > > > <Realm another.realm>
> > > > > 	AuthByPolicy ContinueAlways
> > > > > 	AuthBy SQLAccounting
> > > > > 	<AuthBy ....>
> > > > > 		....
> > > > > 	</AuthBy>
> > > > > 	.....
> > > > > </Realm>
> > > > >
> > > > > .....
> > > > >
> > > > >
> > > > > regards
> > > > >
> > > > > Hugh
> > > > >
> > > > > On Tue, 14 May 2002 01:02, sysadmin at bigbrain.net wrote:
> > > > > > I want to put in a central radius accountinng server and was
> > > > >
> > > > > wondering how
> > > > >
> > > > > > to configure my realms.  I have some realms that I proxy for
> > > > >
> > > > > and some I do
> > > > >
> > > > > > not.  Right now I have all the realms going to a file.  Is
> > > > >
> > > > > there a way I
> > > > >
> > > > > > can tell the realms to fwd to a central server?  Right now I am
> > > > > > just saving them to files.
> > > > > >   If I do this, will it also still fwd the start/stop packets to
> > > > > > the radius servers I am proxying to?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > ===
> > > > > > 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.
> > >
> > > ===
> > > 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.
>
> ===
> 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.

-- 
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.


More information about the radiator mailing list