(RADIATOR) Version 3.7.1 released

2003-09-26 Thread Mike McCauley
We are pleased to announce the release of Radiator version 3.7.1

This version contains an important fix for a typo that was introduced
in version 3.7 as well as support for EAP Generic Token Card

As usual, the new version is available free of charge to current 
licensees from 
http://www.open.com.au/radiator/downloads/

and to current evaluators from 
http://www.open.com.au/radiator/demo-downloads

An extract from the history file is attached

Revision 3.7.1 (2003-09-26 Important bug fix, support for EAP Generic Token 
Card) 

AuthBy RADIUS now correctly handles replies of type
Disconnect-Request-ACKed. Contributed by Robert Thomson.

Added support for EAP Generic Token Card (EAP type 6). Modifications
so that AuthBy OPIE can be used to authenticate EAP-One-Time-Password,
EAP-Token Card and EAP-PEAP Token Card from the OPIE one-time-password
system. Tested with Funk Odyssey client. Improvments to radpwtst,
added the -eapotp and -eapgtc arguemnts to support testing of EAP
One-Time-Password and EAP Generic Token Card.

Added support for EAP Generic Token Card and EAP-PEAP Token Card with
AuthBy ACE and the SecurID ACE server token code system. Sample config
file in goodies/eap_gtc_ace.cfg. AuthBy ACE will also work with EAP
PEAP Generic Token Card similar to eap_peap_gtc_opie.cfg.

Fixed a typo in attribute parsing that could cause an error like ERR:
Bad attribute=value pair:. This typo was introduced in version 3.7.

-- 
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, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

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


Re: (RADIATOR) eap_ttls.cfg Typo?

2003-09-26 Thread Mike McCauley
Hello Terry,


On Fri, 26 Sep 2003 03:44 pm, Terry Simons wrote:
 Howdy,

 After upgrading to Radiator 3.7 I'm getting the following error:

 Reply-Message = EAP TTLS inner authentication redespatched to a
 Handler

 Things worked just fine in 3.6... :)

 I took a look in eap_ttls.cfg, but it looks like there is a typo...

 There is a starting Realm DEFAULT declaration, but it ends with a
 /Handler tag.

This is incorrect, but innocuous, and would not explain what you are seeing.

I think we will need to see your Radiator log file at trace level 4 showing 
what happens during authentication.
What type of TTLS authentication are you using?

What does AuthBy ACCT-TEST  in your config file refer to? I think we 
will need to see your entore config file (no secrets)

Cheers.



 That doesn't quite look right...

 I guess I'll give the eap_ttls_proxy.cfg handler method a try...

 Should this work the way I have it configured, or did I do something
 wrong?

 Here's the offending realm definition:

 Realm DEFAULT
 RewriteUsername s/^([EMAIL PROTECTED]).*/$1/
 AcctLogFileName %L/accounting/accounting.acct

  RejectHasReason

  AuthByPolicyContinueAlways

  AuthBy ACCT-TEST

  AuthLog FILE
  Filename%L/authlog/authlog.log
  LogSuccess  1
  LogFailure  1
  SuccessFormat   %l,%u,%{NAS-Identifier},%N,%h,OK
  FailureFormat   %l,%u,%{NAS-Identifier},%N,%h,FAIL
  /AuthLog
 RewriteUsername s/^([EMAIL PROTECTED]).*/$1/

 AuthBy FILE
 Filename/usr/local/etc/users
 EAPType TTLS TLS MD5-Challenge MSCHAP-V2
 EAPTLS_MaxFragmentSize  1024
 EAPTLS_CAFile   /etc/radiator/CA.pem
 EAPTLS_CertificateType  PEM
 EAPTLS_CertificateFile  /etc/radiator/Server.pem
 EAPTLS_PrivateKeyFile   /etc/radiator/Server.pem
 EAPTLS_PrivateKeyPassword   PrivateKey

 EAPTLS_SessionResumption 0
 AutoMPPEKeys

 /AuthBy
 /Realm

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

-- 
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, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

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


Re: (RADIATOR) Bad attribute=value pair in 3.6

2003-09-26 Thread Mike McCauley
Hello,


On Fri, 26 Sep 2003 02:03 pm, Tech wrote:
 I to have had the same problem but this only started after I had
 downloaded the last patches for 3.6. I was running 3.6 with the patches
 that were aval around May of this year with no problems.

This was due to a typo that was introduced in 3.7. We have just released 3.7.1 
that should fix this problem on all OSs.

Cheers.


 William Hernandez wrote:
  Hello Hugh,
 
  I had the same problem in 3.7, and changing the radius.cfg file
  as mentioned seemed to work. The users file remains as before.
 
  We're on RH 9 (2.4.18-3smp).
  Using Perl 5.6.1.
  Hardware is a Dell PowerEdge 2300.
 
  Regards,
  William
 
  -Original Message-
  From: Hugh Irvine [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, September 24, 2003 6:58 PM
  To: William Hernandez
  Cc: [EMAIL PROTECTED]
  Subject: Re: (RADIATOR) Bad attribute=value pair in 3.6
 
  Hello William -
 
  This is most curious.
 
  Could you try something for me? Download and test Radiator 3.7
  and see
  if it fixes the problem.
 
  Please let me know how you get on, and could you also tell me
  what
  hardware/software platform you are running on and what version of
  Perl?
 
  regards
 
  Hugh
 
  On Thursday, Sep 25, 2003, at 04:48 Australia/Melbourne, William
 
  Hernandez wrote:
   Hugh,
  
   Just to let you know the outcome of this issue.
  
   It looks like the problem is in the radius.cfg.
  
   Our radius.cfg is basically the same as it was when we started
 
  with
 
   Radiator 2.15. More Handlers have been added since 2.15
  
   The following change in radius.cfg worked and ended the Bad
   attribute=value pair errors. (i.e, I removed the space before
 
  and
 
   after the equal sign).
  
   AddToReply Service-Type=Framed-User, \
Framed-Protocol=PPP, \
Framed-IP-Netmask=255.255.255.255, \
Framed-Compression=Van-Jacobson-TCP-IP, \
Ascend-Idle-Limit=900
  
   I will mention that the above only had to be changed in
 
  radius.cfg.
 
   Our users file works with the space before and after the equal
 
  sign.
 
   Do you think I should do a global replace to eliminate the
 
  spaces in
 
   the users file?
  
   Regards,
   William
  
  
   -Original Message-
   From: Hugh Irvine [mailto:[EMAIL PROTECTED]
   Sent: Saturday, September 20, 2003 5:47 AM
   To: William Hernandez
   Cc: 'Radiator'
   Subject: Re: (RADIATOR) Bad attribute=value pair in 3.6
  
  
  
   Hello William -
  
   If you are running on a recent Redhat version, see the FAQ item
 
  here
 
   (and you should also install the latest Radiator patches).
  
 http://www.open.com.au/radiator/faq.html#127
  
   Otherwise there may be a problem earlier in your configuration
 
  file.
 
   regards
  
   Hugh
  
  
   On Friday, Sep 19, 2003, at 07:45 Australia/Melbourne, William
  
   Hernandez wrote:
   Hello everyone,
  
   I'm upgrading from 3.3.1 to 3.6 plus patches.
  
   Using the same radius.cfg in 3.6 as was used in 3.3.1 I'm
  
   getting the
  
   following:
  
   Thu Sep 18 17:33:46 2003: ERR: Bad attribute=value pair:
  
   Service-Type
  
   = Framed-User, Framed-Protocol = PPP, Framed-IP-Netmask =
   255.255.255.255, Framed-Compression = Van-Jacobson-TCP-IP,
   Ascend-Idle-Limit = 900
  
   Radius.cfg has the following:
  
  AddToReply Service-Type = Framed-User, \
   Framed-Protocol = PPP, \
   Framed-IP-Netmask = 255.255.255.255, \
   Framed-Compression = Van-Jacobson-TCP-IP, \
   Ascend-Idle-Limit = 900
  
   Is there a syntax change in 3.6?
  
   Thanks in advance,
   William Hernandez
  
  
   ===
   Archive at http://www.open.com.au/archives/radiator/
   Announcements on [EMAIL PROTECTED]
   To unsubscribe, email '[EMAIL PROTECTED]' 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, MacOS X.
   -
   Nets: internetwork inventory and management - graphical,
   extensible, flexible with hardware, software, platform and
   database independence.
 
  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, 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 [EMAIL PROTECTED]
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.

 ===
 Archive at 

(RADIATOR) High availability radius

2003-09-26 Thread Igor Briski

Hello!

We had some problems in the past regarding our main database server
(Oracle). The problem is, when the database slows down (it is still
accepting connections but runs very slow) Radiator starts slowing down
too and my NAS boxes eventually timeout. So all my users start getting
rejected. 

Both of our Radiator servers connect to the same database, so we
generally have a single point of failure. 

Is there any way to configure Radiator so that when it detects a very
slow database it stops using it (similar behaviour when the database
goes down, it backs off). 

Authorization part is using .db files, so when the database is not
available authorization can continue. But when the database is slow, the
whole thins slows down to a point where the system is not usable. 

Any comments, suggestions? 

-- 
Igor Briski [EMAIL PROTECTED]

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


(RADIATOR) Authentication to one DB, Accounting to another

2003-09-26 Thread Derek Buttineau
Just want to make sure I'm not totally out in left field on how to 
accomplish this, I thought I'd ask.  We just recently setup MySQL 
Replication.. and I'd like to make our Radiator software use the master 
and slaves for authentication (just using DNS round robin atm).. but 
since only the master can receive updates, I'd like to make sure the 
accounting packets only go to the master.

I'm thinking I need to make the configuration look like this, but please 
let me know if I'm totally off base:

   AuthByPolicy ContinueAlways

   AuthBy SQL
   DBSourcedbi:mysql:radius:Slave Hostname
   DBUsernameusername
   DBAuthpassword
   # Setup Authentication
   AuthSelectselect ENCRYPTEDPASSWORD, REPLYATTR from 
AUTHENTICATIONTABLE where USERNAME='%U'
   AuthColumnDef0, Encrypted-Password, check
   AuthColumnDef1, GENERIC, reply

   # Disable Accounting
   AccountingTable
   /AuthBy
   AuthBy SQL
   DBSourcedbi:mysql:radius:Master Database
   DBUsernameradius
   DBAuthcsrox
   # Disable Authentication
   AuthSelect
   # Setup Accounting
   AccountingTable ACCOUNTINGTABLE
   AcctColumnDef   USERNAME,User-Name
   AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%Y%m%d 
%H:%M:%S'
   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-IP-Address
   AcctColumnDef   NASPORT,NAS-Port,integer
   AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
   AcctColumnDef   CONNECTSPEED,Connect-Speed
   /AuthBy

Thanks a bunch in advance.  Sorry if this has already been covered on 
the list, took a look but perhaps my search techniques are in need of 
improvement :)

--
Regards,
Derek Buttineau
Internet Systems Administrator
Compu-SOLVE Internet Services
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.


(RADIATOR) PostAuthHook and DB connection

2003-09-26 Thread S H A N
hi,
i am trying to think of a method where i can avoid 

connect to db
do something...
disconnect from db

each time one of my hook gets processing in a radius operation for each
postauth request. (so if it handles 100k packets it means that i does
100k times connect to db and 100k times of disconnect!)

ideally i want..

to connect to db... (at the point of startup of radius)

keep on doing something without disconnecting/connecting again
till the life of the radius session/process.

any suggestions?

S H A N
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.


RE: (RADIATOR) High availability radius

2003-09-26 Thread Frank Danielson
Igor-

It sounds like you are using the Oracle database for storing accounting data
only. If that is the case how about runnning an instance of Radiator on each
box for authentication and another instance of Radiator for accounting? That
way authentication should not be affected by database problems.

-Frank

-Original Message-
From: Igor Briski [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 4:06 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) High availability radius



Hello!

We had some problems in the past regarding our main database server
(Oracle). The problem is, when the database slows down (it is still
accepting connections but runs very slow) Radiator starts slowing down
too and my NAS boxes eventually timeout. So all my users start getting
rejected. 

Both of our Radiator servers connect to the same database, so we
generally have a single point of failure. 

Is there any way to configure Radiator so that when it detects a very
slow database it stops using it (similar behaviour when the database
goes down, it backs off). 

Authorization part is using .db files, so when the database is not
available authorization can continue. But when the database is slow, the
whole thins slows down to a point where the system is not usable. 

Any comments, suggestions? 

-- 
Igor Briski [EMAIL PROTECTED]

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


RE: (RADIATOR) High availability radius

2003-09-26 Thread Igor Briski
On Pet, 2003-09-26 at 13:59, Frank Danielson wrote:
 Igor-
 
 It sounds like you are using the Oracle database for storing accounting data
 only. If that is the case how about runnning an instance of Radiator on each
 box for authentication and another instance of Radiator for accounting? That
 way authentication should not be affected by database problems.

Actually, that's not the case. I use Oracle for authentication too
(Session database, address allocator etc.). 

Thanks anyway. 

-- 
Igor Briski [EMAIL PROTECTED]

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


RE: (RADIATOR) PostAuthHook and DB connection

2003-09-26 Thread Frank Danielson
You can use an existing database handle from an AuthBy SQL or SessSQL in
your hook. This not only reduces the overhead of disconnecting and
reconnecting to the db each time but also lets you leverage the work that
Radiator does behing the scenes to manage the db connection.   Here is an
excerpt from a post by Hugh to the mailing list that explains the details.
The original message can be found here -
http://www.open.com.au/archives/radiator/2000-06/msg00023.html

I use this technique in several hooks and it works just dandy.


.
# configuration to allow a PostAuthHook to access a database
# either define a new AuthBy SQL if different to an existing AuthBy SQL
# or add an Identifier tag to your existing AuthBy SQL

AuthBy SQL
Identifier yourSQL
DBSource 
DBUsername 
DBAuth 
/AuthBy


Then in your hook use the find function in AuthGeneric to retrieve the
reference
to that AuthBy SQL. Once you have the reference, you can use all the
standard
routines in AuthSQL.pm and SqlDb.pm, including prepareAndExecute, etc.

# hook to use an SQL database

sub
{
my $p = ${$_[0]};
my $rp = ${$_[1]};
my $result = ${$_[2]};

my $authby_handle = Radius::AuthGeneric::find('yourSQL');
my $query = select ..;
my $sth = $authby_handle-prepareAndExecute($query);
.
}

This way you avoid most of the housekeeping, as it is already taken care of
by
the routines in SqlDb.pm. As a relatively simple example of some SQL code
that
uses these routines, have a look at Radius/SessSQL.pm.



Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 
-Original Message-
From: S H A N [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 6:45 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) PostAuthHook and DB connection


hi,
i am trying to think of a method where i can avoid 

connect to db
do something...
disconnect from db

each time one of my hook gets processing in a radius operation for
each
postauth request. (so if it handles 100k packets it means that i
does
100k times connect to db and 100k times of disconnect!)

ideally i want..

to connect to db... (at the point of startup of radius)

keep on doing something without disconnecting/connecting
again
till the life of the radius session/process.

any suggestions?

S H A N
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.


RE: (RADIATOR) Authentication to one DB, Accounting to another

2003-09-26 Thread Frank Danielson
The only catch is that AuthBy SQL will open a connection to the database
when it starts up and keep that connection up unless there is a problem with
it so your round robin DNS will not do much. AuthBY SQL supports declaring a
database to use as a backup which may be a better scheme for reliability. If
you are looking to load balance among your databases I would run a Radiator
instance for each database instance and then proxy requests to them using a
main instance with AuthBy ROUNDROBIN or AuthBy LOADBALANCE.

-Frank

-Original Message-
From: Derek Buttineau [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 6:20 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Authentication to one DB, Accounting to another


Just want to make sure I'm not totally out in left field on how to 
accomplish this, I thought I'd ask.  We just recently setup MySQL 
Replication.. and I'd like to make our Radiator software use the master 
and slaves for authentication (just using DNS round robin atm).. but 
since only the master can receive updates, I'd like to make sure the 
accounting packets only go to the master.

I'm thinking I need to make the configuration look like this, but please 
let me know if I'm totally off base:

AuthByPolicy ContinueAlways

AuthBy SQL
DBSourcedbi:mysql:radius:Slave Hostname
DBUsernameusername
DBAuthpassword

# Setup Authentication
AuthSelectselect ENCRYPTEDPASSWORD, REPLYATTR from 
AUTHENTICATIONTABLE where USERNAME='%U'
AuthColumnDef0, Encrypted-Password, check
AuthColumnDef1, GENERIC, reply

# Disable Accounting
AccountingTable
/AuthBy

AuthBy SQL
DBSourcedbi:mysql:radius:Master Database
DBUsernameradius
DBAuthcsrox

# Disable Authentication
AuthSelect

# Setup Accounting
AccountingTable ACCOUNTINGTABLE
AcctColumnDef   USERNAME,User-Name
AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%Y%m%d 
%H:%M:%S'
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-IP-Address
AcctColumnDef   NASPORT,NAS-Port,integer
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDef   CONNECTSPEED,Connect-Speed
/AuthBy

Thanks a bunch in advance.  Sorry if this has already been covered on 
the list, took a look but perhaps my search techniques are in need of 
improvement :)

-- 
Regards,

Derek Buttineau
Internet Systems Administrator
Compu-SOLVE Internet Services


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