AW: (RADIATOR) PM3 and completing Authenication

Martin Wallner Martin.Wallner at eunet.co.at
Thu May 4 19:00:38 CDT 2006


Oh-oh.... this is just an Idea, and has nothing to do with PM3 in special, but
 
_MAYBE_ you should add something like this in your rewrite ....
 
RewriteUsername        tr/[A-Z]/[a-z]/
 
<Realm /^xxxx.xxx$/i>
 
and then in your AuthSelect:
AuthSelect select PASSWORD \
        from SUBSCRIBERS \
                where USERNAME = lower('%n')

(careful, I didn't look it after, lower() is for sure in postgres, I didn't check mysql, but there should be a similar function)...

With this 2 precautions (and only a little bit overhead) you make SURE that the you work only with lower case characters... in the 'pure' form, Radiator is HIGHLY case sensitive.... :-) If you get even more cautious, you can make a filter for ALL the characters you want to allow, so that whitespace and nonprintable errors can't occure...

As I said, just an Idea (and a few years ago, I was sitting on the same problem until I looked at the debug out from a Cisco AND a trace 4 at the same time.. :-) 

=mw=

 

________________________________

Von: Mike Gomez [mailto:mgomez at iland.net]
Gesendet: Do 04.05.2006 23:25
An: Martin Wallner
Cc: Hugh Irvine; radiator at open.com.au
Betreff: Re: (RADIATOR) PM3 and completing Authenication



I'm using ComOS 3.9.1c1.  I put in the 'ignoreacctsignature' and upped the
time on the PM3 and that seems to have partially solved my problem.  The
users I've setup in my mysql database I did via importing a comma separated
value file all work okay(just username/password, no checkattr or replyattr). 
Any that I've setup via the mysql command line (again just putting in a
username/password, no checkattr or replyattr) do the same thing as before,
they just cycle through getting an Auth: Accept and sending the reply, but
then I see another access-request come through again.  I even tried putting a
couple of test username/passwords into a text file and importing them like I
did the original batch, but they won't work as well.  Here's an example of an
entry that works (password and domain XXXX'd out to protect the guilty ;)  :

mysql> select * from SUBSCRIBERS where username = 'jthadavis at xxxxxx.xxx';
+----------------------+----------+-------------------+-----------+-----------+----------+
| USERNAME             | PASSWORD | ENCRYPTEDPASSWORD | CHECKATTR | REPLYATTR
| TIMELEFT |
+----------------------+----------+-------------------+-----------+-----------+----------+
| jthadavis at xxxxxx.xxx | xxxx   | NULL              | NULL      | NULL      |    
NULL |
+----------------------+----------+-------------------+-----------+-----------+----------+


And one that does not:

mysql> select * from SUBSCRIBERS where username = 'mgomez at xxxxxx.xxx';
+-------------------+----------+-------------------+-----------+-----------+----------+
| USERNAME          | PASSWORD | ENCRYPTEDPASSWORD | CHECKATTR | REPLYATTR |
TIMELEFT |
+-------------------+----------+-------------------+-----------+-----------+----------+
| mgomez at xxxxxx.xxx | xxxxxxx  | NULL              | NULL      | NULL      |    
NULL |
+-------------------+----------+-------------------+-----------+-----------+----------+

I've even set the radius.cfg file to have:

AuthSelect select PASSWORD \
        from SUBSCRIBERS \
                where USERNAME = '%n'

Instead of trying to include the REPLYATTR and CHECKATTR, but to no avail. 
The top entry works, but the bottom one does not.  Am I crazy?  Am I doing
something wrong?  Do I need more coffee?

Thanks,

Mike

On Wednesday 03 May 2006 10:06, Martin Wallner wrote:
> Mike,
>
> Depends on what kind of PortOS you are using, but sometimes the
> portmasters have problems with the accounting signature (like in they
> can not decrypt or just send nonsense). Just set 'ignoreacctsignature'
> and that should heal most of the problems. Also, don't use too short
> resend-intervals... makes PM's sometimes crazy (it's an OLD CPU working
> in there.. give it some breathing space... :-)...
>
> I'm not using PM3's anymore, but that about sums up my problems I had
> with these boxes and radiator, and I used them a LONG time...
>
> Good source for this info (especially, after Lucent killed the
> PM-Series) is www.portmasters.com, especially the Lists there...
>
> =mw=
>
> > -----Original Message-----
> > From: owner-radiator at open.com.au
> > [mailto:owner-radiator at open.com.au] On Behalf Of Mike Gomez
> > Sent: Mittwoch, 03. Mai 2006 16:15
> > To: Hugh Irvine
> > Cc: radiator at open.com.au
> > Subject: Re: (RADIATOR) PM3 and completing Authenication
> >
> > This unfortunately didn't seem to help.  I still get the same
> > thing, it just cycles over and over again.  There aren't any
> > firewalls between, the PM3 plugs into a vlan switch and then
> > to the same router that the radius server plugs into, via the
> > same vlan switch.  I didn't see any access lists on the
> > router that would block this traffic.
> >
> > I've looked up the PM3 manuals and troubleshooting guides
> > online, but I didn't really see anything in particular on
> > what it wanted as a reply attribute specifically.  Has anyone
> > setup radiator to work with a PM3?  If so, care to share the
> > config? ;)
> >
> > Thanks!
> > --
> > Mike Gomez
> >
> > On Monday 17 April 2006 19:02, Hugh Irvine wrote:
> > > Hello Mike -
> > >
> > > You should check the PM3 documentation for details,
> >
> > although typical
> >
> > > reply attributes that you might try are these:
> > >
> > >
> > >  <AuthBy SQL>
> > >   .....
> > >   AddToReply Service-Type = Framed-User, \
> > >    Framed-Protocol = PPP
> > >  </AuthBy>
> > >
> > >
> > > However from what you describe it could also be that there
> >
> > are filters
> >
> > > or firewalls blocking the return path to the PM3.
> > >
> > > hope that helps
> > >
> > > regards
> > >
> > > Hugh
> > >
> > > On 17 Apr 2006, at 19:19, Mike Gomez wrote:
> > > > Hi there,
> > > >
> > > > I'm trying to setup radiator to be used by some PM3
> >
> > units.  When I
> >
> > > > have users try to connect, it says "AuthBy SQL result: ACCEPT" in
> > > > the logs, but the PM3 never lets the user authenticate, it just
> > > > retries over and over again.  I saw an email on the mailing list
> > > > that was the exact same problem
> > > > (http://www.open.com.au/archives/radiator/2002-02/msg00215.html)
> > > > and it was
> > > > stated it could be a reply attribute problem, but I didn't see a
> > > > solution ever posted.  I'm posting my cfg file and the
> >
> > output of my
> >
> > > > logs.
> > > > If someone
> > > > could tell me what I'm doing wrong, I would be very thankful! :)
> > > >
> > > > radius.cfg(with secrets and IPs X'd out):
> > > > LogFile %L/%Y%m-logfile
> > > > LogDir          /var/log/radius/
> > > > DbDir           .
> > > > # User a lower trace level in production systems:
> > > > Trace           4
> > > >
> > > > # You will probably want to add other Clients to suit
> >
> > your site, #
> >
> > > > one for each NAS you want to work with <Client DEFAULT>
> > > >         Secret  mysecret
> > > >         DupInterval 0
> > > > </Client>
> > > > <SessionDatabase SQL>
> > > > Identifier InSQL
> > > > DBSource dbi:mysql:radius:xxx.xxx.xxx.xxx
> > > >        DBUsername XXXX
> > > >        DBAuth XXXXX
> > > >       </SessionDatabase>
> > > > <Realm DEFAULT>
> > > > RewriteUsername s/^([^@]+)$/$1\@hopper.net/ <AuthBy SQL>
> > > >         DBSource dbi:mysql:radius:xxx.xxx.xxx.xxx
> > > >           DBUsername XXXX
> > > >              DBAuth XXXX
> > > > AuthSelect select PASSWORD,CHECKATTR,REPLYATTR \
> > > >         from SUBSCRIBERS \
> > > >                 where USERNAME = '%n'
> > > > AccountingTable ACCT%Y%m
> > > >                 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    ACCTTERMINATECAUSE,Ascend-
> > > > Disconnect-Cause
> > > >                 AcctColumnDef    NASPORT_TYPE,NAS-Port-Type
> > > >                 AcctColumnDef    NASADDRESS,NAS-IP-Address
> > > >                 AcctColumnDef    FRAMEDADDRESS,Framed-IP-Address
> > > >                 AcctColumnDef    NASIDENTIFIER,NAS-Identifier
> > > >                 AcctColumnDef    NASPORT,NAS-Port,integer
> > > >                 AcctColumnDef    USRCONSPEED,Connect-Speed
> > > >                 AcctColumnDef    USRCONSPEED,Connect-Info
> > > >                 AcctColumnDef    MODULATION,Modulation-Type
> > > >                 AcctColumnDef    CSI,Calling-Station-Id
> > > >
> > > >
> > > >         </AuthBy>
> > > >         # Log accounting to a detail file
> > > >         AcctLogFileName ./detail
> > > > </Realm>
> > > >
> > > >
> > > >
> > > > Log file:
> > > > *** Received from 209.192.77.5 port 3461 ....
> > > > Code:       Access-Request
> > > > Identifier: 22
> > > > Authentic:
> > > > <178><233><157><255><166>,<163><30>g<205><14>s<144><19><245>
> > > > Attributes:
> > > >         User-Name = "test"
> > > >         CHAP-Password =
> > > > "<1><218><232><211>b<194><127>X<177>_<243><242>936<192><
> > > > 188>"
> > > >         NAS-IP-Address = xxx.xxx.xxx.xxx
> > > >         NAS-Port = 1
> > > >         NAS-Port-Type = Async
> > > >         Service-Type = Framed-User
> > > >         Framed-Protocol = PPP
> > > >         Connect-Info = "26400 LAPM/NONE"
> > > >         Called-Station-Id = "xxxx"
> > > >         Calling-Station-Id = "xxxx"
> > > >
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Handling request with Handler
> > > > 'Realm=DEFAULT'
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Rewrote user name to
> > > > test at hopper.net Mon Apr 17 04:12:43 2006: DEBUG: InSQL Deleting
> > > > session for test, xxx.xxx.xxx.xxx, 1 Mon Apr 17 04:12:43 2006:
> > > > DEBUG: do query is: 'delete from RADONLINE where NASID
> > > > ENTIFIER='209.192.77.5' and NASPORT=01':
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Handling with
> >
> > Radius::AuthSQL Mon
> >
> > > > Apr 17 04:12:43 2006: DEBUG: Handling with Radius::AuthSQL:
> > > >
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Query is: 'select
> > > > PASSWORD,CHECKATTR,REPLYATTR from SUBSCRIBERS where USERNAME =
> > > > 'test at hopper.net'':
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Radius::AuthSQL looks for match
> > > > with test@ hopper.net [ledmo4798]
> > > >
> > > > Mon Apr 17 04:12:43 2006: DEBUG: Radius::AuthSQL ACCEPT: :
> > > > test at hopper.net
> > > > [test]
> > > > Mon Apr 17 04:12:43 2006: DEBUG: AuthBy SQL result:
> >
> > ACCEPT, Mon Apr
> >
> > > > 17 04:12:43 2006: DEBUG: Access accepted for
> >
> > test at hopper.net Mon Apr
> >
> > > > 17 04:12:43 2006: DEBUG: Packet dump:
> > > > *** Sending to 209.192.77.5 port 3461 ....
> > > > Code:       Access-Accept
> > > > Identifier: 22
> > > > Authentic:
> > > > <178><233><157><255><166>,<163><30>g<205><14>s<144><19><245>
> > > > Attributes:
> > > >
> > > >
> > > >
> > > >
> > > > And then it just repeats this same sequence about 6 times before
> > > > giving up.
> > > >
> > > > Thanks!
> > > > --
> > > > Mike Gomez
> > > >
> > > > --
> > > > 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.
> > >
> > > NB:
> > >
> > > Have you read the reference manual ("doc/ref.html")?
> > > Have you searched the mailing list archive
> >
> > (www.open.com.au/archives/
> >
> > > radiator)?
> > > Have you had a quick look on Google (www.google.com)?
> > > Have you included a copy of your configuration file (no secrets),
> > > together with a trace 4 debug showing what is happening?
> >
> > --
> > Mike Gomez
> > Network Operations Center
> > I-Land Internet Services
> > 660.829.4638 Ext. 130
> >
> > --
> > 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.

--
Mike Gomez
Network Operations Center
I-Land Internet Services
660.829.4638 Ext. 130


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060505/05e3c2d5/attachment.html>


More information about the radiator mailing list