(RADIATOR) message
Terry Simons
galimore at mac.com
Wed Dec 29 19:32:20 CST 2004
Hi Jeff,
I suspect that the problem might lie in your use of both Handlers and
Realms in your configuration.
It has been mentioned several times on the list that this is not
recommended, but that if you need to use Handlers, use Handlers only.
You can get a "default" Handler by doing the following:
<Handler>
#Authentication gunk
</Handler>
So you can replace your Default realm with that instead.
I don't know if this will fix the problem, but it's a good first step.
- Terry
On Dec 29, 2004, at 4:38 PM, Jeff Tuttle - AllisonRoyce.com wrote:
> Having a problem trying to use realms or handlers to accomplish the
> following:
>
>
>
> We desire to have two separate databases of users authenticate from
> the same radius and access server.
>
>
>
> We want callers from phone number 7000 to authenticate from table A
> and callers from phone number 8000 to authenticate from table B. We
> also want callers from phone number 7000 to write to accounting table
> A and callers from phone number B to write to accounting table B. Here
> is our config file below and for the life of us we can’t seem to get
> it working. We keep getting “Could not find handler for user <blah>”
> Any help is appreciated.
>
>
>
> Need an example of how to make the handler work w/v3.11 to accomplish
> this, thanks to all.
>
> # windows.cog
> #
> # Example Radiator configuration file.
> # This very simple file will allow you to get started with
> # a simple system on Windows. You can then add and change features.
> # We suggest you start simple, prove to yourself that it
> # works and then develop a more complicated configuration.
> #
> # This example is expected to be installed in
> # c:\Program Files\Radiator\radius.cfg
> # It will authenticate from a standard users file in
> # c:\Program Files\Radiator\users
> # it will log debug and other messages to
> # c:\Program Files\Radiator\logfile
> # and log accounting to a file in
> # c:\Program Files\Radiator\detail
> # (of course you can change all these by editing this config file if
> you wish)
> #
> # It will accept requests from any client and try to handle requests
> # for any realm.
> # And it will print out what its doing in great detail to the log
> file.
> #
> # See radius.cfg for more complete examples of features and
> # syntax, and refer to the reference manual for a complete description
> # of all the features and syntax.
> #
> # You should consider this file to be a starting point only
> # $Id: windows.cfg,v 1.1 2003/03/27 09:41:28 mikem Exp $
>
> Foreground
> # Run in the foreground
>
> LogStdout
> # Log to stdout
>
> Trace 4
> # This will log at DEBUG level: very verbose
> # User a lower trace level in production systems, typically use 3
> # 0 ERR. Error conditions. Serious and unexpected failures
> # 1 WARNING. Warning conditions. Unexpected failures
> # 2 NOTICE. Normal but significant conditions.
> # 3 INFO. Informational messages.
> # 4 DEBUG. Debugging messages.
> # 5 Incoming raw packet dumps in hexadecimal.
>
> LogDir c:/Program Files/Radiator/logs
> # aka %L, Put log files in c:/Program Files/Radiator
>
> LogFile %L/%m-%Y-logfile.log
> # Log file goes in c:/Program Files/Radiator, with month & year number
>
> DbDir c:/Program Files/Radiator
> # aka %D, Look in c:/Program Files/Radiator for username database
>
> AuthPort 1645,1812
> # Listen for authentication requests on port 1812 as per RFC 2138.
> # You could listen for requests on the 2 most comon Radius
> # authentication port numbers with 'AuthPort 1645,1812'
>
> AcctPort 1646,1813
> # JT Listen for accounting requests on port 1813 as per RFC 2139.
> # You could listen for requests on the 2 most comon Radius accounting
> # port numbers with 'AuthPort 1646,1813'
>
> BindAddress x.x.x.2,127.0.0.1
> # Only listen on one (or more) network address
> # Could also use 'BindAddress x.x.x.2,x.x.x.22'
>
> DictionaryFile %D/dictionary
> # Dictionary file is in the DbDir directory
> # Need to load more than one dictionary file at the same time like
> the old Ascend non-vendor-specific attribtues too
> # DictionaryFile %D/dictionary,%D/dictionary.ascend
>
> PidFile %L/radiusd.pid
> # The file where radiusd will write its process ID (PID) at start-up,
> so we don’t conflict with another radiusd
>
> SnmpgetProg c:/usr/bin
> # Specifies the full path name to the snmpget program. This optional
> parameter is only
> # used if you are using Simultaneous-Use with a NasType of Livingston
> or any other NAS
> # type that uses SNMP (see Figure 3 on page 29) in one of your Client
> clauses. Defaults
> # to /usr/bin/snmpget.
>
> LivingstonMIB
> # This optional parameter specifies the name of the Livingston SNMP
> MIB. It is only
> # used if you are using Simultaneous-Use with a NasType of Livingston
> in one of your
> # Client clauses. Defaults to
> .iso.org.dod.internet.private.enterprises.307
>
> UsernameCharset a-zA-Z0-9\._ at -
> # This optional parameter checks that every user name consists only
> of the characters in
> # the specified character set . This can be useful to reject acceess
> requests that are due to
> # modem line noise. The value of the parameter is a perl character
> set specification. The
> # default is to permit all ASCII characters. See your Perl reference
> manual for details
> # about how to construct perl character set specifications.
> # This example permits only alphanumeric, period, dash and the at
> sign (note that the special
> # characters ‘.’ is escaped with a backslash):
>
> <Log SQL>
> # Connect to mSQL with database named ‘xxx’
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
> # This optional clause creates an SQL logger, which will log all
> messages with a priority
> # level of Trace or more to an SQL database. The logging is in
> addition to any logging to
> # the file defined by LogFile (see Section 6.4.9 on page 21).
> # The messages will be inserted with the following SQL statement:
> #
> # Insert into a table called RADLOG
> Table RADLOG
> # Trace level, refer to above trace notes
> Trace 4
> insert into RADLOG (TIME_STAMP, PRIORITY, MESSAGE) \
> values (time, priority, ’message’)
> </Log>
>
> # <Log FILE>
> # </Log FILE>
>
> <AuthLog SQL>
> # The clause indicates to log authentication successes and failures
> to an SQL database.
> # You can define as many <AuthLog SQL> clauses as you wish at the top
> level or within
> # Realm or Handler clauses. Each clause can specify different logging
> conditions and a
> # different log database.
> # As well as the generic parameters described in Section 6.52 on page
> 147, AuthLog SQL
> # understands the following parameters:
> # These parameters specify how to connect to the database to use for
> logging. They need
> # to be set in a similar way to as for <AuthBy SQL>. They specify the
> DBD driver, database
> # and username to connect to, and how to handle SQL server failures.
> # # Connect to mSQL with database named ‘radius’
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
>
> #
> Table RADAUTHLOG
> # This optional parameter specifies the name of the SQL table where
> the logging messages
> # are to be inserted. Defaults to RADAUTHLOG.
> </AuthLog>
>
> <AuthLog FILE>
> Identifier logger1
> Filename %L/authlog1
> LogSuccess 1
> LogFailure 1
> </AuthLog>
>
> <StatsLog FILE>
> Filename %L/stats
> # This clause logs statistics from all Radiator internal objects to a
> flat file. There is an
> # example configuration file in goodies/statslog.cfg.
> # Interval
> # This is the time interval (in seconds) between each set of
> statistics. Defaults to 600 seconds
> # (10 minutes).
> # Interval 600
> # Log once per day:
> Interval 86400
> # Log the timestamp, objtype, name and average response time:
> Format %0:%1:%2:%23
> # Header:
> # This optional paramter allows you to customise the Header line that
> is logged before
> # each set of statistics. It can be useful for describing the
> contents of each column when
> # importing into Excel etc.
> # The default is a single line beginning with a hash, followed a name
> for each colmn,
> # colon separated.
> # If Header is defined as an empty string, no Header lines will be
> written.
> # No headers
> # Header
> </StatsLog>
>
>
>
> <StatsLog SQL>
> # This clause logs statistics from all Radiator internal objects to
> an SQL database. There
> # is an example configuration file in goodies/statslog.cfg.
> # See Section 6.60 on page 160 for a discussion about what data is
> available for logging.
> # By default, StatsLog SQL executes an SQL insert statement for each
> object to be
> # logged, which includes a timestamp, object type, object name, and
> each statistic available
> # for logging.
> # StatsLog SQL understands the following parameters:
> # 6.61.1 DBSource, DBUsername, DBAuth, Timeout, FailureBackoffTime
> # These parameters specify how to connect to the SQL database. They
> need to be set in a
> # similar way to as for <AuthBy SQL> (see Section 6.28 on page 82).
> They specify the
> # DBD driver, database and username to connect to, and how to handle
> SQL server failures.
> # Connect to mSQL with database named ‘xxx’:
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
>
> # 6.61.2 Interval
> # This is the time interval (in seconds) between each set of
> statistics. Defaults to 600 seconds
> # (10 minutes).
> # Interval 600
> # Log once per day:
> Interval 86400
> # 6.61.3 InsertQuery
> # This optional parameter specifies the SQL query to be used for each
> log. It can include
> # special formatting characters as described in Section 6.2 on page
> 14. %0 to %23 are
> # replaced by statistics data as described in Section 6.60.3 on page
> 162.
> # The default is an SQL query something like this, which is
> compatible with the example
> # RADSTATSLOG table created by the example database schemas in
> goodies.
> InsertQuery insert into RADSTATSLOG (TIME_STAMP, TYPE, IDENTIFER,
> <symbolic stats names>) values (9999999, ‘objectname’,
> ‘objectidentifier’, <statistics values>) \
> # Here is an example that only logs a subset of the statistics:
> # InsertQuery insert into MYTABLE (TIME_STAMP, TYPE, ID, \
> # RESPONSETIME) values (%0, %1, %2, %23)
> </StatsLog>
>
>
> #<Client DEFAULT>
> # # You will probably want to add other Clients to suit your site,
> # # one for each NAS you want to work with. This will work
> # # at least with radpwtst running on the local machine
> # Secret mysecret99999
> # DupInterval 0
> #</Client>
>
>
>
>
> <ClientListSQL>
> # Connect to mSQL with database named ‘xxx’
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
> #
> GetClientQuery select \
> NASIDENTIFIER,SECRET,IGNOREACCTSIGNATURE,DUPINTERVAL, \
> DEFAULTREALM,NASTYPE,SNMPCOMMUNITY,LIVINGSTONOFFS, \
> LIVINGSTONHOLE,FRAMEDGROUPBASEADDRESS, \
> FRAMEDGROUPMAXPORTSPERCLASSC,REWRITEUSERNAME, \
> NOIGNOREDUPLICATES,PREHANDLERHOOK \
> from RADCLIENTLIST
> </ClientListSQL>
>
> <SessionDatabase SQL>
> # Here is a useful name for this Session Database
> Identifier SDB1
> #
> # Connect to mSQL with database named ‘xxx’
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
>
> #
> AddQuery insert into RADONLINE (USERNAME, NASIDENTIFIER, NASPORT, \
> ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS, NASPORTTYPE, \
> SERVICETYPE) values ('%u', '%1', %2, %3, %{Timestamp}, \
> '%{Framed-IP-Address}', '%{NAS-Port-Type}', '%{Service-Type}')
> #
> DeleteQuery delete from RADONLINE where NASIDENTIFIER='%1' and
> NASPORT=0%2
> #
> #ClearNasQuery delete from RADONLINE where NASIDENTIFIER=’%0’
> #
> CountQuery select \
> NASIDENTIFIER, NASPORT, ACCTSESSIONID, FRAMEDIPADDRESS \
> from RADONLINE where USERNAME='%u'
> #
> # This SQL statement is executed whenever Radiator needs the number
> of sessions currently
> # logged on to a particular NAS. This is only required if
> HandleAscendAccessEventRequest
> # is defined and an Ascend-Access-Event-Request is received. %1 is
> replaced
> # by the NAS ip address.
> # It defaults to:
> #
> # CountNasSessionsQuery select ACCTSESSIONID from RADONLINE where
> NASIDENTIFIER=’%0’
> #
> # This SQL statement is executed whenever Radiator needs the number
> of sessions currently
> # logged on to a particular NAS. This is only required if
> HandleAscendAccessEventRequest
> # is defined and an Ascend-Access-Event-Request is received and
> Radiator
> # finds that there is a sesison in the session database that is not
> recorded in the NAS. %1 is
> # replaced by the NAS ip address and %2 is replaced by the session ID.
> # It defaults to:
> #
> ClearNasSessionQuery delete from RADONLINE where NASIDENTIFIER='%1'
> and ACCTSESSIONID = '%3'
>
> </SessionDatabase>
>
> <SNMPAgent>
> # Example, showing how to enable SNMP handling
> ROCommunity remote411ara
> #
> # Use a non-standard port
> Port 9991
> #
> # Only listen on one network, not all the ones connected
> BindAddress x.x.x.2
> #
> # Allowed SNMP managers
> # This optional parameter specifies a list of SNMP managers that have
> access to
> # SNMPAgent. The value is a list of host names or addresses,
> separated by white space or
> # comma. You can have any number of Managers lines. Defaults to
> nothing with all hosts
> # allowed.
> # Managers foo.bar.edu 192.168.1.11, noc.rz.uni-ulm.de
> Managers x.x.x.2
> </SNMPAgent>
>
>
> <Handler Calling-Station-Id=/2105647001/>
>
> <AuthBy SQL>
> DBSource dbi:ODBC:RADIUS3
> DBUsername xxx
> DBAuth xxx
>
> AccountingTable ACCOUNTINGPORTMASTER
>
> AcctColumnDef USERNAME,User-Name
> AcctColumnDef TIME_STAMP,Timestamp,integer-date
> 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
> AcctColumnDef CALLEDSTATIONID,Called-Station-Id
> AcctColumnDef CALLERID,Calling-Station-Id
>
> #
> AuthSelect select \
> PASSWORD, CHECKATTR, REPLYATTR \
> from SUBSCRIBERSPORTMASTER \
> where USERNAME=%0
> #
>
> AuthColumnDef 0, User-Password, check
> AuthColumnDef 1, GENERIC, check
> AuthColumnDef 2, GENERIC, reply
>
> AcctFailedLogFileName %L/missedacctPortmaster
>
> SQLRecoveryFile %L/missedacctPortmaster
> </AuthBy>
> </Handler>
>
>
> <Realm DEFAULT>
>
>
>
> <AuthBy SQL>
> # Adjust DBSource, DBUsername, DBAuth to suit your DB
> #
> DBSource dbi:ODBC:xxx
> DBUsername xxx
> DBAuth xxx
> #
> # 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,User-Name
> #Comment out by Jon Lindley 12/27/2004
> AcctColumnDef TIME_STAMP,Timestamp,integer-date
> # or
> # 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
> AcctColumnDef CALLEDSTATIONID,Called-Station-Id
> AcctColumnDef CALLERID,Calling-Station-Id
>
> #
> # These are the columns used by Emerald for reference:
> # NASIdentifier,NAS-Identifier
> # NASPort,NAS-Port,integer
> # AcctSessionID,Acct-Session-Id
> # AcctStatusType,Acct-Status-Type
> # CallDate,Timestamp,integer
> # UserName,User-Name
> # UserService
> # AcctDelayTime,Acct-Delay-Time,integer
> # AcctSessionTime,Acct-Session-Time,integer
> # FramedProtocol
> # FramedAddress,Framed-IP-Address
> # AcctInputOctets,Acct-Input-Octets,integer
> # AcctOutputOctets,Acct-Output-Octets,integer
> # AcctTerminateCause,Acct-Terminate-Cause
> # NASPortType
> # NASPortDNIS
> # AcctSessionID_New
> #
> #
> AuthSelect select \
> PASSWORD, CHECKATTR, REPLYATTR \
> from SUBSCRIBERS \
> where USERNAME=%0
> #
> AuthColumnDef 0, User-Password, check
> AuthColumnDef 1, GENERIC, check
> AuthColumnDef 2, GENERIC, reply
> # Hint: this has the same effect as the default rule that Radiator
> # applies if no AuthColumnDef parameters are specified at all.
> #
> # 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 %L/missedaccounting
> #
> # Alternatively, you can arrange to save failed SQL accounting insert
> queries to a text
> # file with SQLRecoveryFile
> SQLRecoveryFile %L/missedaccounting
> #
> # You can run a hook whenever Radiator (re)connects to the database.
> This
> # can be useful for doing database-specific config or setup
> # The hook is called like hook($object, $handle)
> # $object is the SqlDb object that is doing the connecting,
> # and $handle is the database handle if the newly connected database
> # This example shows how to set some connection specific attributes
> # for Interbase
> #ConnectionHook sub {$_[1]->func(-access_mode => 'read_write',\
> # -isolation_level => 'read_committed',\
> # -lock_resolution => 'wait',\
> # 'ib_set_tx_param')}
> </AuthBy>
> # # Authenticate all realms with this
> # # Look up user details in a flat file
> # <AuthBy FILE>
> # # %D is replaced by DbDir above
> # Filename %D/users
> # </AuthBy>
> #
> # # Log accounting to a detail file. %D is replaced by DbDir above
> # AcctLogFileName %D/detail
>
> </Realm>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 44436 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20041229/d14cbebf/attachment.bin>
More information about the radiator
mailing list