(RADIATOR) Radiator using SQL

'Tunde Ogedengbe tunde at linkserve.net
Wed Jul 25 14:53:49 CDT 2001


I am reconfiguring Radiator to use an SQL database.  Connection is to be
made via ODBC.

1.    How do I define the data structure in the database to accomodate all
Radius attributes ?
2.    How do I setup Radiator to query the database and return relevant
attributes associated with the record. eg. Simultaneous-use, filter-id, etc.



'Tunde Ogedengbe
----- Original Message -----
From: "Hugh Irvine" <hugh at open.com.au>
To: "Roger Mangraviti" <rem at atu.com.au>
Cc: <radiator at open.com.au>
Sent: Wednesday, July 25, 2001 8:47 AM
Subject: Re: (RADIATOR) appending realm to the end of a user.


>
> Hello Roger -
>
> What you show below will not work because the AuthBy RADIUS clause does
not
> operate in the way you are expecting, and in any case the AuthByPolicy
that
> you are using will not do the right thing. The reason for this is that the
> AuthBy RADIUS clause is asynchronous and returns immediately, therefore
the
> AuthByPolicy will not work correctly.
>
> If you explain what you are trying to do, I will be happy to make some
> suggestions.
>
> Note that we also offer consulting and installation services if required.
>
> regards
>
> Hugh
>
>
> On Wednesday 25 July 2001 16:18, Roger Mangraviti wrote:
> > Hi Hugh,
> >
> > I have been playing with the config a bit and i'm trying to achieve the
> > following:
> >
> > account to one sql server, with the realm appended to the user.
> > proxy auth to 2 different radius auth servers.
> >
> > the problem being is that customers may not be appending a realm to the
> > username.
> > this is the main part of my config:
> >
> >
> >
> > <Realm DEFAULT>
> >
> > #strip realm
> > RewriteUsername s/^([^@]+).*/$1/
> >
> > AuthByPolicy ContinueUntilAccept
> >
> >         <AuthBy SQL>
> >         # Adjust DBSource, DBUsername, DBAuth to suit your DB
> >
> >         DBSource        dbi:mysql:radius:localhost
> >         DBUsername      radius
> >         DBAuth          xx
> >
> >         # You may want to tailor these for your ACCOUNTING table
> >         # You can add your own columns to store whatever you like
> >         AccountingTable ACCOUNTING
> >
> >         AcctColumnDef   USERNAME,UserName
> >         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
> >         AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> >
> >         # You can arrange to log accounting to a file if the
> >         # SQL insert fails with AcctFailedLogFileName
> >         # That way you could recover from a broken SQL
> >         # server
> >         #AcctFailedLogFileName %D/missedaccounting
> >         </AuthBy>
> >
> >
> >         <AuthBy RADIUS>
> >         AuthenticateAccounting
> >
> >                 AddToReply Class = atu.com.au
> >
> >                 FailureBackoffTime 60
> >
> >                 Synchronous
> >
> >                 Secret xx
> >                 RetryTimeout 1
> >                 Retries 1
> >
> >                 <Host 203.202.66.13>
> >                 AuthPort        1812
> >                 AcctPort        1813
> >                 </Host>
> >
> >         AcctFailedLogFileName %D/missedaccounting
> >
> >         </AuthBy>
> >
> >
> >         <AuthBy RADIUS>
> >         AuthenticateAccounting
> >
> >                 AddToReply Class = viper.net.au
> >
> >                 FailureBackoffTime 60
> >
> >                 Synchronous
> >
> >                 Secret xx
> >                 RetryTimeout 1
> >                 Retries 1
> >
> >
> >                 <Host 203.31.238.1>
> >                 AuthPort        1812
> >                 AcctPort        1813
> >                 </Host>
> >
> >         AcctFailedLogFileName %D/missedaccounting
> >
> >         </AuthBy>
> >
> > </Realm>
> >
> >
> > authentication seems to work (for a while till it freezes, which i need
to
> > debug), but the sql logging is not
> > appending the realm to the username.
> >
> >
> >
> > -----Original Message-----
> > From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
> > Behalf Of Hugh Irvine
> > Sent: Friday, 20 July 2001 1:50 PM
> > To: Roger Mangraviti; radiator at open.com.au
> > Subject: Re: (RADIATOR) appending realm to the end of a user.
> >
> >
> >
> > Hello Roger -
> >
> > On Friday 20 July 2001 13:09, Roger Mangraviti wrote:
> > > Hello,
> > >
> > > we have 2 radius servers and a radiator box. We are not appending the
> >
> > realm
> >
> > > to the username, as we have 2 realms
> > > dialing the same number on the same nas.
> > >
> > > We have authentication working using fall through AuthBy RADIUS, but
we
> > > need to append the realm for accounting purposes. How can the realm be
> > > append to if we know which radius server the user was authenticated
from?
> >
> > The simplest way to do this is with the Class attribute, which can be
added
> > to the access accept. If you send me a copy of your configuration file
(no
> > secrets) I will show you how to set this up. Typically you would use an
> > AddToReply:
> >
> > <AuthBy RADIUS>
> > .....
> > AddToReply Class = some.realm
> > </AuthBy>
> >
> > 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 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.
>

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