(RADIATOR) Accounting dictionary for netserver card

1999-06-03 Thread O Stockhammer


Hello,
We are using both Netserver and Hyperarc TotalControl Cards.
Radiator is authenticating fine off of both but the Netserver Cards are
missing entries for the dictionary file and therefore no accounting 
happens for them.
For some reason I am missing entries in the dictionary file for
the netserver card.  I am using your dictionary.usr file that you
provided.  What entries do I need for accounting to work?

I think it has to do with the vendor specific entries like

USR-Chassis-Call-Slot = 0
rather than 
Chassis-Call-Slot = 0 which is in the dictionary file

Thank you,
Oliver Stockhammer
Systems
The Internet Channel


===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Accounting dictionary for netserver card

1999-06-04 Thread O Stockhammer


These are from the logfile:

Fri Jun  4 16:44:12 1999: ERR: Attribute number 0 (vendor ) is not defined
in your dictionary
Fri Jun  4 16:45:18 1999: ERR: Attribute number 73 (vendor ) is not
defined in your dictionary
Fri Jun  4 16:45:18 1999: ERR: Attribute number 116 (vendor ) is not
defined in your dictionary
Fri Jun  4 16:46:24 1999: ERR: Attribute number 240 (vendor ) is not
defined in your dictionary
Thu Jun  3 20:31:37 1999: ERR: Attribute number 144 (vendor ) is not
defined in your dictionary

These are the logs from the SQL log:

928528731  4 Rewrote user name to
kaligula

928528731  4 Handling with
Radius::AuthSQL

928528731  4Handling with
Radius::AuthUNIX

928528731  4Radius::AuthUNIX looks for match with
kaligula

928528731  4  Radius::AuthUNIX
ACCEPT:

928528731  4  Access accepted for 
kaligula

928528736  1   Bad authenticator in request from 207.240.140.6 
(207.240.140.6)

This is what I get at trace level 5.  I am logging both to a logfile and
MySQL and accounting is going to both a detail file and MySQL.  Accounting
works for my other chassies using Hyperarc cards.

Thanks,
Oliver

On Fri, 4 Jun 1999, Mike McCauley wrote:

 Hi Oliver,
 
 can you send us a fragment of your radiator log file at trace level 4, showing
 what happens when you receive accounting packets from your Netserver. I would
 exepct to see Radiator complaining about missing dictionary entries. That will
 help us track down the missing attributes.
 
 Cheers.
 
 
 On Jun 3,  8:49pm, O Stockhammer wrote:
  Subject: (RADIATOR) Accounting dictionary for netserver card
 
  Hello,
  We are using both Netserver and Hyperarc TotalControl Cards.
  Radiator is authenticating fine off of both but the Netserver Cards are
  missing entries for the dictionary file and therefore no accounting
  happens for them.
  For some reason I am missing entries in the dictionary file for
  the netserver card.  I am using your dictionary.usr file that you
  provided.  What entries do I need for accounting to work?
 
  I think it has to do with the vendor specific entries like
 
  USR-Chassis-Call-Slot = 0
  rather than
  Chassis-Call-Slot = 0 which is in the dictionary file
 
  Thank you,
  Oliver Stockhammer
  Systems
  The Internet Channel
 
 
  ===
  Archive at http://www.thesite.com.au/~radiator/
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.
 -- End of excerpt from O Stockhammer
 
 
 
 -- 
 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
 


===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Accounting dictionary for netserver card

1999-06-07 Thread O Stockhammer


IgnoreAcctSignature seems to have rectified the accting interference.

Thanks,
Oliver

On Mon, 7 Jun 1999, Mike McCauley wrote:

 Hi Oliver,
 
 On Jun 4,  4:57pm, O Stockhammer wrote:
  Subject: Re: (RADIATOR) Accounting dictionary for netserver card
 
  These are from the logfile:
 
  Fri Jun  4 16:44:12 1999: ERR: Attribute number 0 (vendor ) is not defined
  in your dictionary
 That is quite bizarre, there is no such attribute
 
  Fri Jun  4 16:45:18 1999: ERR: Attribute number 73 (vendor ) is not
  defined in your dictionary
 So is that.
 
  Fri Jun  4 16:45:18 1999: ERR: Attribute number 116 (vendor ) is not
  defined in your dictionary
 That is supposedly Ascend-Appletalk-Route
 
  Fri Jun  4 16:46:24 1999: ERR: Attribute number 240 (vendor ) is not
  defined in your dictionary
 That is supposedly Ascend-Add-Seconds
 
  Thu Jun  3 20:31:37 1999: ERR: Attribute number 144 (vendor ) is not
  defined in your dictionary
 That is Ascend-Assign-IP-Client
 
 That all looks very strange, almost as if the incoming packet is corrupted in
 being incorrectly interpreted. Can you send a hex packet dump of one of these
 requests? You can get het packet dumps at trace level 5.
 
 
 
 
  These are the logs from the SQL log:
 
  928528731  4 Rewrote user name to
  kaligula
 
  928528731  4 Handling with
  Radius::AuthSQL
 
  928528731  4Handling with
  Radius::AuthUNIX
 
  928528731  4Radius::AuthUNIX looks for match with
  kaligula
 
  928528731  4  Radius::AuthUNIX
  ACCEPT:
 
  928528731  4  Access accepted for
  kaligula
 
  928528736  1   Bad authenticator in request from 207.240.140.6
  (207.240.140.6)
 
  This is what I get at trace level 5.  I am logging both to a logfile and
  MySQL and accounting is going to both a detail file and MySQL.  Accounting
  works for my other chassies using Hyperarc cards.
 
 It seems lime auth is working, but accounting is complaining about  "Bad
 authenticator". This is usually an indication that you need IgnoreAcctSignature
 set for that NAS. But in the light of the very strange results above, it may be
 something else. The packet dump will help.
 
 Im sorry you are having this trouble. I hope we get you on the air soon.
 
 Cheers.
 
  Thanks,
  Oliver
 
  On Fri, 4 Jun 1999, Mike McCauley wrote:
 
   Hi Oliver,
  
   can you send us a fragment of your radiator log file at trace level 4,
 showing
   what happens when you receive accounting packets from your Netserver. I
 would
   exepct to see Radiator complaining about missing dictionary entries. That
 will
   help us track down the missing attributes.
  
   Cheers.
  
  
   On Jun 3,  8:49pm, O Stockhammer wrote:
Subject: (RADIATOR) Accounting dictionary for netserver card
   
Hello,
We are using both Netserver and Hyperarc TotalControl Cards.
Radiator is authenticating fine off of both but the Netserver Cards are
missing entries for the dictionary file and therefore no accounting
happens for them.
For some reason I am missing entries in the dictionary file for
the netserver card.  I am using your dictionary.usr file that you
provided.  What entries do I need for accounting to work?
   
I think it has to do with the vendor specific entries like
   
USR-Chassis-Call-Slot = 0
rather than
Chassis-Call-Slot = 0 which is in the dictionary file
   
Thank you,
Oliver Stockhammer
Systems
The Internet Channel
   
   
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
   -- End of excerpt from O Stockhammer
  
  
  
   --
   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
  
 
 
  ===
  Archive at http://www.thesite.com.au/~radiator/
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.
 -- End of excerpt from O Stockhammer
 
 
 
 -- 
 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+, pa

(RADIATOR) (Radiator) Setting up radius.cfg for Groups

1999-06-08 Thread O Stockhammer


Hello,
With the flexibility of radiator, I wanted to know if you
suggested a method of implementing different session characteristics for
different unix group members.  I know we have to use 'check items' but I
am unsure of how to insert them in the cfg file. 
For example,  we would like to use the 'maxsessions 1' for the
'nodup' unix group, while everyone else coming in should be set to
'maxsessions 5'.  I am hoping to implement this in the radius.cfg file
using something like a Handler tag.  I am just unsure as to where this
info should go in the the actual file.  
I have attached part of my current (rudimentary) radius.cfg file.
The way we are setup is to have all accounting go to mySQL and
authentication first goes off of a UNIX master.passwd file and then to a
users file.  Ipass will be a future consideration. 
Thanks for your help.  

Oliver Stockhammer 
Systems
Internet Channel


LogStdout
PidFile /var/log/radius/radiator.pid
LogDir /var/log/radius
DbDir /usr/local/etc/radiusDB

#SnmpgetProg/usr/bin/snmpget

# This clause defines a single client to listen to
Client ancillary.inch.com
Secret  
NasType TotalControl
/Client

# This is on of the USR racks at oldslip for accting only.
Client 207.240.212.131
Secret 
NasType TotalControl
/Client

Client 207.240.142.3
Secret 
NasType TotalControl
/Client

Client 207.240.142.5
Secret 
NasType TotalControl
/Client

Client 207.240.142.7
Secret 
NasType TotalControl
/Client

Client 207.240.142.9
Secret 
NasType TotalControl
/Client

Client 207.240.142.11
Secret 
NasType TotalControl
/Client

Client 207.240.140.6
Secret 
IgnoreAcctSignature
NasType TotalControl
/Client

# For testing: this allows us to honour requests from radpwtst 
# on the same host.
Client localhost
Secret mysecret
DupInterval 0
/Client

Realm DEFAULT
RewriteUsername s/^([^@]+).*/$1/
AcctLogFileName %L/detail
AuthByPolicyContinueUntilAccept
AuthBy SQL
DBSourcedbi:mysql:Radiator
DBUsername  root 
DBAuth  
# an empty AuthSelect turns off auth
AuthSelect  

AccountingTable ACCOUNTING
   AcctColumnDef   USERNAME,User-Name
AcctColumnDef   CLIENT_ID,Client-Id
   AcctColumnDef   TIME_STAMP,Timestamp,integer
AcctColumnDef   ACTUAL_TIME,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   NAS_IDENTIFIER,Client-Id
   AcctColumnDef   NAS_IP_ADDRESS,NAS-IP-Address
   AcctColumnDef   NAS_PORT,NAS-Port,integer
AcctColumnDef   NAS_PORT_TYPE,NAS-Port-Type
AcctColumnDef   ACCTAUTHENTIC,Acct-Authentic
AcctColumnDef   SERVICE_TYPE,Service-Type   
AcctColumnDef   USR_MODEM_TIME,USR-Modem-Training-Time,integer
AcctColumnDef   USR_INTERFACE,USR-Interface-Index,integer
AcctColumnDef   USR_CHASSIS_SLOT,Chassis-Call-Slot,integer
AcctColumnDef   USR_CHASSIS_SPAN,Chassis-Call-Span,integer
AcctColumnDef   USR_CHASSIS_CHANNEL,Chassis-Call-Channel,integer
AcctColumnDef   USR_UNAUTH_TIME,Unauthenticated-Time,integer
AcctColumnDef   CALLING_STATION_ID,Calling-Station-Id
AcctColumnDef   CALLED_STATION_ID,Called-Station-Id
AcctColumnDef   USR_MODULATION_TYPE,Modulation-Type
AcctColumnDef   USR_SMNP_LEVELS,Simplified-MNP-Levels
AcctColumnDef   USR_SimplifiedV42BIS_USAGE,Simplified-V42bis-Usage
AcctColumnDef   USR_CONNECT_SPEED,Connect-Speed
AcctColumnDef   FRAMED_PROTOCOL,Framed-Protocol
AcctColumnDef   FRAMED_IP_ADDRESS,Framed-IP-Address
AcctColumnDef   USR_MP_MRRU,MP-MRRU,integer
AcctColumnDef   ACCTLINKCOUNT,Acct-Link-Count,integer
AcctColumnDef   ACCTMULTISESSION_ID,Acct-Multi-Session-Id 
/AuthBy
AuthBy UNIX
Identifier System
Filename /usr/local/etc/radiusDB/master.passwd

Re: (RADIATOR) (Radiator) Setting up radius.cfg for Groups

1999-06-10 Thread O Stockhammer


I am having problems with this.  The problem is that we are using AuthBy
SQL for accounting only and AuthBy UNIX for the actual authentication, 
followed by a AuthBy FILE for secondary authentication. I am using an
AuthByPolicy of ContinueUntilAccept and have all the AuthBy's in one realm
called DEFAULT.

I tried to use your method below in a number of configurations and
although it does seem to be going from the "xyzzy" file to the AuthBy Unix
file, it is not applying any of the group permissions to particular group
members.  I am having quite a bit of difficulty testing this, and have
been using both Simulateous-Use=1 and Session-Timeout=30.

What we want is to be able to set different permissions for particular
members of different groups.  At the same time, we must be able to 
use mySQL accounting.  I do not know if all this is possible.  I am
attaching our radius.cfg file again.  This is including our current
configuration without the new AuthBy FILE clause you told me to insert
below.  I am still alittle unclear as to where to put the new AuthBy
FILE clause and the AuthBy UNIX.  Also, I will attach the rudimentary
"xyzzy" file that I was using?  Am I missing anything?

Oliver Stockhammer
Systems
Internet Channel

On Wed, 9 Jun 1999, Mike McCauley wrote:

 Hello Oliver.
 
 Its very difficult to distinguish between Unix groups of users using Handlers
 or Realm. Handler and realm only have the attributes of the incoming request to
 work with. I think the right answer for you is to set up a users file that
 authenticates through Unix, and uses check and reply items for each group.
 Something like this:
 
 Realm DEFAULT
   AuthBy FILE
   Filename xyzzy
   /AuthBy
 /Realm
 
 # This one is used by AuthType=System
 AuthBy UNIX
   Identifier System
   Filename /etc/passwd
   GroupFilename /etc/group
 /AuthBy
 
 And in the users file xyzzy:
 
 # Limit of 5 sim-use to anyone in group1
 DEFAULT AuthType=System,Group=group1,Simultaneous-Use=5
 
 # Limit of 2 sim-use for anyone in group2
 DEFAULT AuthType=System,Group=group2,Simultaneous-Use=2
 
 etc
 
 Hope that helps.
 
 Cheers.
 
 
 On Jun 8, 10:59am, O Stockhammer wrote:
  Subject: (RADIATOR) (Radiator) Setting up radius.cfg for Groups
 
 
  Hello,
  With the flexibility of radiator, I wanted to know if you
  suggested a method of implementing different session characteristics for
  different unix group members.  I know we have to use 'check items' but I
  am unsure of how to insert them in the cfg file.
  For example,  we would like to use the 'maxsessions 1' for the
  'nodup' unix group, while everyone else coming in should be set to
  'maxsessions 5'.  I am hoping to implement this in the radius.cfg file
  using something like a Handler tag.  I am just unsure as to where this
  info should go in the the actual file.
  I have attached part of my current (rudimentary) radius.cfg file.
  The way we are setup is to have all accounting go to mySQL and
  authentication first goes off of a UNIX master.passwd file and then to a
  users file.  Ipass will be a future consideration.
  Thanks for your help.
 
  Oliver Stockhammer
  Systems
  Internet Channel
 
  [ Attachment (text/plain): "radius.cfg.partial" 6571 bytes
Character set: US-ASCII
Partial radius.cfg
Encoded with "base64" ]
 -- End of excerpt from O Stockhammer
 
 
 
 -- 
 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
 


LogStdout
PidFile /var/log/radius/radiator.pid
LogDir /var/log/radius
DbDir /usr/local/etc/radiusDB

#SnmpgetProg/usr/bin/snmpget

# This clause defines a single client to listen to
Client ancillary.inch.com
Secret  
NasType TotalControl
/Client

# This is on of the USR racks at oldslip for accting only.
Client 207.240.212.131
Secret 
NasType TotalControl
/Client

Client 207.240.142.3
Secret 
NasType TotalControl
/Client

Client 207.240.142.5
Secret 
NasType TotalControl
/Client

Client 207.240.142.7
Secret 
NasType TotalControl
/Client

Client 207.240.142.9
Secret 
NasType TotalControl
/Client

Client 207.240.142.11
Secret 
NasType TotalControl
/Client

Client 207.240.140.6
Secret 
IgnoreAcctSignature
NasType TotalControl
/Client

# For testing: this allows us to honour requests fro

Re: (RADIATOR) Ipass Perl Module and FreeBSD 3

1999-08-04 Thread O Stockhammer


There were no complilation errors in the make phase. -oliver

On Wed, 28 Jul 1999, Mike McCauley wrote:

 
  Hello,
  We are currently running FreeBSD 3.x and using Radiator to
  authenticate users.  We are trying to implement Ipass.  I have already
  installed Ipass and it tests properly.  We have hit a snag trying to
  install the Ipass Perl Module from Open Systems.  Here are the errors we
  have gotten:
  
  ~~~
  root[ancillary]/home/oliver/SRC/IpassPerl-1.3 {132}# make test
  PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib
  -I/usr/libdata/perl/5.00503/mach -I/usr/libdata/perl/5.00503 test.pl
  1..6
  Can't load 'blib/arch/auto/Ipass/Ipass.so' for module Ipass:
  blib/arch/auto/Ipass/Ipass.so: Undefined symbol "ipass_debug" at
  /usr/libdata/perl/5.00503/DynaLoader.pm line 169.
 
 That looks a lot like the compilation of the IpassPerl module failed. Did you
 see any errors when you did the "make" phase?
 
 Cheers.
 
 
 
  
   at test.pl line 19
  BEGIN failed--compilation aborted at test.pl line 19.
  not ok 1
  *** Error code 255
  
  Stop.
  ~
  
  I have run the LIB with and without the -lndbm flag and it has made no
  difference.  Any suggestions?
  
  Thanks,
  Oliver Stockhammer
  
  
  ===
  Archive at http://www.thesite.com.au/~radiator/
  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, 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.
 
 
 
 -- 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, 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) AuthBy SQL Accting Tables. (fwd)

1999-08-13 Thread O Stockhammer


Hugh, here are the ACCOUNTING logs for two identical logins and the
corresponding (by timestamp) RADLOG entries.  One successfully updated and
one did not.  There were no error logs corresponding in the text logfile.
My only guess is that perhaps mysql failed to input the entry, although
there is not any sign of that either.

The PreAuthHook directive worked quite well, and is serving us quite well.
We will be using that solution.  Thanks for your help.

Cheers-
Oliver

On Fri, 13 Aug 1999, Hugh Irvine wrote:

 
 Hi Oliver -
 
 On Fri, 13 Aug 1999, O Stockhammer wrote:
  Hugh,
  Is there anyway to actually have Radiator append info to the
  incoming data, so that it only uses on query per request?  
  I have created an AcctSQLStatement, but it seems because it is an
  additional query that it doesn't update the row of data in mysql every 
  time (It misses a few Acct submissions here and there).  Here is what I am
  using:
  
  AcctSQLStatementUpdate ACCOUNTING set ORIGIN ='Auth-2:
  local' where TIME_STAMP = %{Timestamp} and NAS_IDENTIFIER = '%N' and
  NAS_PORT= '%{NAS-Port}'
  
  The purpose of the query is to ID the realm and radiator server
  which is doing the Authentication(The value of ORIGIN changes for each
  Realm) . It there anyway to have radiator include this data in the
  original ACCTING queries, so that it is all in one, so to speak?  Perhaps
  there is an easy way to modify AcctColumnDef to have a fourth field which
  is the actual value for the column.
  
 
 Hmmm. I am perplexed to imagine how your configuration could miss any updates,
 given that the insert and the update are executed sequentially with the same
 packet. It would be most enlightening to see a debug at trace level 4 to see
 what is going on.
 
 But to answer your question, yes you can set up a PreAuthHook to insert a
 pseudo-attribute into the packet and you can even use the special formatting
 character "%h" to set it to the Radiator hostname. Then you can use the
 standard AcctColumnDef to insert the value directly into the original
 accounting record. This is probably a better solution in any case.
 
 There is an example PreAuthHook in Section 6.13.10 of the Radiator 2.14.1
 reference 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
 


  kaligula  934495962  Aug 12, 1999 18:12  Start  1.2.34.5  1234   Auth-2: 
@inch.com  
  kaligula  934495962  Aug 12, 1999 18:12   Stop  1.2.34.5  1234
  kaligula  934495972  Aug 12, 1999 18:12  Start  1.2.34.5  1234
  kaligula  934495973  Aug 12, 1999 18:12   Stop  1.2.34.5  1234


934495962  4  Handling request with Handler 'Realm=inch.com'  
934495962  4   Rewrote user name to kaligula  
934495962  4   Handling with Radius::AuthSQL  
934495962  4  Handling with Radius::AuthFILE  
934495962  4  Radius::AuthFILE looks for match with kaligula  
934495962  4  Handling with Radius::AuthUNIX  
934495962  4  Radius::AuthUNIX looks for match with kaligula  
934495962  4Radius::AuthUNIX ACCEPT:  
934495962  4Radius::AuthFILE ACCEPT:  
934495962  4Access accepted for kaligula  
934495962  4  Handling request with Handler 'Realm=inch.com'  
934495962  4   Rewrote user name to kaligula  
934495962  4   Handling with Radius::AuthSQL  
934495962  4Handling accounting with Radius::AuthSQL  
934495962  4  do query is: Update ACCOUNTING set ORIGIN = 'Auth-2: @inch.com' where 
TIME_STAMP = 934495962 and NAS_IDENTIFIER = '1.2.34.5' and NAS_PORT= '1234'
  
934495962  4  do query is: insert into ACCOUNTING
(USERNAME, NAS_PORT_TYPE, SERVICE_TYPE, ACCTSTATUSTYPE, 
NAS_IDENTIFIER, NAS_PORT, ACTUAL_TIME, CLIENT_ID, ACCTSESSIONID, TIME_STAMP) 
values 
('kaligula', 'As  
934495962  4 Adding session for kaligula, 1.2.34.5, 1234  
934495962  4  do query is: delete from RADONLINE where USERNAME='kaligula' and 
NAS_IDENTIFIER='1.2.34.5' and NAS_PORT=1234
  
934495962  4  do query is: insert into RADONLINE (USERNAME, NAS_IDENTIFIER, NAS_PORT, 
ACCTSESSIONID, TIME_STAMP, FRAMED_IP_ADDRESS, NAS_PORT_TYPE, 
SERVICE_TYPE,USR_MODULATION_TYPE ,USR_CONNECT_SPEED) values ('kalig  
934495962  4 Accounting accepted  
934495962  4  Handling request with Handler 'Realm=inch.com'  
934495962  4   Rewrote user name to kaligula  



934495973  4 
Handling request with Handler 'Realm='  
93