(RADIATOR) Bug?
Mike McCauley
mikem at open.com.au
Wed Dec 18 15:01:20 CST 2002
Hello Surajh,
thanks for your note.
On Wed, 18 Dec 2002 20:15, Surajh Surjoo [ MTN Sandhurst ] wrote:
> Unfortunatley, we make extensive use of default users as we do not care
> what username or password the enduser enters, as long as he connects to our
> server. We are a mobile cellular operator and allow users onto our
> Ericsson GGSN on the Internet APN...payment is per kilobyte transferred and
> we have the users MSISDN to bill.
>
> So Please DO NOT put a limit on the number of DEFAULT users, as this will
> severly affect our operations!
OK, we have instead added a new parameter DefaultLimit that allows you to
impose a limit if you wish, but which defaults to no limit.
OK?
Cheers.
>
> thanks
>
> Surajh Surjoo
> Systems Engineer - Data
> Mobile: 0832129829
> Mobile Fax: 083 8 2129829
> Office Fax: 011 3018811
> Office Tel: 011 3016000
> surajh.surjoo at mtn.co.za
>
> "Imagination is more important than Knowledge" - Albert Einstein
>
>
> -----Original Message-----
> From: Mike McCauley [mailto:mikem at open.com.au]
> Sent: Wednesday, 18 December 2002 10:32 AM
> To: Toomas Kärner; Hugh Irvine
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Bug?
>
>
> Hello Toomas,
>
> On Wed, 18 Dec 2002 18:41, Toomas Kärner wrote:
> > Hi all,
> >
> > Sorry, my bad ....
> > I looked at the code, understanded it and looked at the manual again and
> > realized that NoDefault is affective in case of REJECT and NOT only in
> > case on Not found. That started my little snowball. Only real idea that
> > grew out of this is that maybe $defaultNumber should have a limit. With
> > my loop I created 52000 request's to SQL and I can't think a reason why
> > someone should need so many defaults and would allow them in so big cost
> > of load. I think 512 should by way enough.
>
> OK, we have added a limit of 512 DEFAULT users for the next release.
> Thanks for the suggestion.
>
> Cheers.
>
> > Rgds and appologies.
> > Toomas Kärner
> >
> > ----- Original Message -----
> > From: "Hugh Irvine" <hugh at open.com.au>
> > To: "Toomas Kärner" <tomkar at estpak.ee>; <mikem at open.com.au>
> > Cc: <radiator at open.com.au>
> > Sent: Friday, December 13, 2002 11:50 PM
> > Subject: Re: (RADIATOR) Bug?
> >
> > > Hello Toomas -
> > >
> > > The fundamental issue is the architecture of Radiator itself and
> > > specifically the AuthBy clauses, all of which fundamentally implement a
> > > "find_user" routine which is why you see the problem that you do.
> > >
> > > You are correct that what I show below is a workaround, ie. the first
> > > AuthBy uses a couple of DEFAULT entries so that "find_user" works, then
> > > passes off the request using the Auth-Type construct to an AuthBy
> > > clause in which you can do anything you like.
> > >
> > > The extra processing overhead is minimal, as the AuthBy FILE will cache
> > > the DEFAULT lines in memory and will simply do a couple of memory
> > > lookups.
> > >
> > > I encourage you to have a look at the code in "Radius/AuthGeneric.pm"
> > > and "Radius/AuthSQL.pm" to see what goes on.
> > >
> > > I have also copied this mail to Mike for his additional comments.
> > >
> > > regards
> > >
> > > Hugh
> > >
> > >
> > > On Friday, Dec 13, 2002, at 22:26 Australia/Melbourne, Toomas Kärner
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > So, AuthBy's like:
> > > > ########################################
> > > > <AuthBy SQL>
> > > > Identifier AuthBlacklistCheck
> > > > DBSource dbi:mysql:
> > > > DBUsername
> > > > DBAuth
> > > > AuthSelect select MACADDRESS, REPLYMESSAGE from macblacklist where \
> > > > MACADDRESS like '%{Calling-Station-Id}' and \
> > > > ACTIVE = 'Yes'
> > > >
> > > > AuthColumnDef 0, Service-Type,check
> > > > AuthColumnDef 1, Reply-Message,reply
> > > >
> > > > NoDefault
> > > > AcceptIfMissing
> > > > </AuthBy>
> > > > ########################################
> > > > and
> > > > ########################################
> > > > <AuthBy SQL>
> > > > Identifier AuthUser
> > > > DBSource dbi:mysql:
> > > > DBUsername
> > > > DBAuth
> > > >
> > > > AuthSelect select ACTIVE, WNACCESS, CHECKATTR, PASSWORD,\
> > > > REPLYATTR \
> > > > from xxxxxx where USERNAME ='%n'
> > > >
> > > > AuthColumnDef 0, ETC-Admin-Active, check
> > > > AuthColumnDef 1, ETC-Admin-Wireless, check
> > > > AuthColumnDef 2, GENERIC, check
> > > > AuthColumnDef 3, User-Password, check
> > > > AuthColumnDef 4, GENERIC, reply
> > > >
> > > > DefaultSimultaneousUse 1
> > > > NoDefault
> > > > RejectEmptyPassword
> > > >
> > > > AccountingTable log
> > > > AcctColumnDef DATE,Timestamp ,formatted-date,'%Y-%m-%d'
> > > > .
> > > > .
> > > > .
> > > > </AuthBy>
> > > > ########################################
> > > > and realm like
> > > > ########################################
> > > > <Realm admin>
> > > > RewriteUsername s/^([^@]+).*/$1/
> > > > AuthByPolicy ContinueUntilReject
> > > > AuthBy AuthBlacklistCheck
> > > > AuthBy AuthUser
> > > > </Realm admin>
> > > > ########################################
> > > > is impossible because AuthBlacklistCheck has nothing to do with
> > > > usernames
> > > > and that freaks it out to go to loop with DEFAULT? I think that this
> > > > is more
> > > > than configuration issue and configuration that you gave me is more
> > > > like a
> > > > workaround that probably takes more load. If this is true that if no
> > > > such
> > > > thing as username is received from sql results in a new query with
> > > > default
> > > > username then it is impossible to use radiator for authentication of
> > > > layer
> > > > 2. If you are confused what I mean by Layer 2 authentication, this is
> > > > checking layer 2 information for given request and if that succeeds
> > > > then go
> > > > forward with username authentication.
> > > >
> > > > Also from the Archive: 17. oct. 2002 to jlewis at lewis.org you said:
> > > > {
> > > > The reason for doing it this way is because the AuthBy processing is
> > > > looking for a user, which the AuthBy SQL clause is not doing.
> > > > }
> > > > I don't want to do anything with user in that AuthBy, I just want to
> > > > verify
> > > > 2L information. Is that a limitation in Radiator?
> > > >
> > > > Rgds.
> > > > Toomas
> > > >
> > > > ----- Original Message -----
> > > > From: "Hugh Irvine" <hugh at open.com.au>
> > > > To: "Toomas Kärner" <tomkar at estpak.ee>
> > > > Cc: <radiator at open.com.au>
> > > > Sent: Friday, December 13, 2002 12:59 AM
> > > > Subject: Re: (RADIATOR) Bug?
> > > >
> > > >> Hello Toomas -
> > > >>
> > > >> This is not a bug really - it is more a configuration issue.
> > > >>
> > > >> The problem that you show below is due to the fact that the AuthBy
> > > >> is looking for the username, and you are overriding it to look for
> > > >> something else. This leads to the AuthBy continuing to look for
> > > >> DEFAULT... .
> > > >>
> > > >> The correct way to build a configuration file to do blacklist
> > > >> checking is to use cascaded AuthBy clauses.
> > > >>
> > > >> Something like this:
> > > >>
> > > >> # define AuthBy clauses
> > > >>
> > > >> <AuthBy SQL>
> > > >> Identifier CheckMACAddress
> > > >> ......
> > > >> </AuthBy>
> > > >>
> > > >> <AuthBy FILE>
> > > >> Identifier CheckBlacklist
> > > >> Filename %D/blacklist
> > > >> </AuthBy>
> > > >>
> > > >> ......
> > > >>
> > > >> # define Realms or Handlers
> > > >>
> > > >> <Realm ...>
> > > >> AuthByPolicy ContinueWhileAccept
> > > >> .....
> > > >> AuthBy CheckBlacklist
> > > >> .....
> > > >> </Realm>
> > > >>
> > > >> .....
> > > >>
> > > >> The SQL table would contain something like this:
> > > >>
> > > >> MACADDRESS ACTION
> > > >> nn.nn.nn.nn.nn.nn Auth-Type = Reject
> > > >> oo.oo.oo.oo.oo.oo Auth-Type = Reject
> > > >>
> > > >> .....
> > > >>
> > > >> The file "blacklist" would contain this:
> > > >>
> > > >> # blacklist
> > > >>
> > > >> DEFAULT Auth-Type = CheckMACAddress
> > > >>
> > > >> DEFAULT Auth-Type = Accept
> > > >>
> > > >> This topic has been discussed on the list many times, so check the
> > > >> archive if you are interested.
> > > >>
> > > >> www.open.com.au/archives/radiator
> > > >>
> > > >> regards
> > > >>
> > > >> Hugh
> > > >>
> > > >>
> > > >> On Thursday, Dec 12, 2002, at 21:38 Australia/Melbourne, Toomas
> > > >> Kärner
> > > >>
> > > >> wrote:
> > > >>> Hi
> > > >>>
> > > >>> When I have config like:
> > > >>>
> > > >>> <Realm plah>
> > > >>> AuthByPolicy ContinueUntilReject
> > > >>> AuthBy Identifier_of_some_authby_that_gives_reject
> > > >>> <AuthBy SQL>
> > > >>> plahplah
> > > >>> </AuthBy>
> > > >>> </Realm plah>
> > > >>>
> > > >>> This kind a conf results loop in
> > > >>> Identifier_of_some_authby_that_gives_reject
> > > >>> and never goes to AuthBy SQL.
> > > >>>
> > > >>> debug 4 of such config (it had other problems as well but it
> > > >>> shouldnt have
> > > >>> gone to loop because MACADDRESS like '00-50-04-E8-B4-AF' was
> > > >>> found).
> > > >>>
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match
> > > >>> with DEFAULT52061
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item
> > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match
> > > >>> 'Login-User' in
> > > >>> request
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS,
> > > >>> REPLYMESSAGE
> > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and
> > > >>> ACTIVE
> > > >>> =
> > > >>> 'Yes'
> > > >>>
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match
> > > >>> with DEFAULT52062
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item
> > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match
> > > >>> 'Login-User' in
> > > >>> request
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS,
> > > >>> REPLYMESSAGE
> > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and
> > > >>> ACTIVE
> > > >>> =
> > > >>> 'Yes'
> > > >>>
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL looks for match
> > > >>> with DEFAULT52063
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Radius::AuthSQL REJECT: Check item
> > > >>> Service-Type expression '00-50-04-E8-B4-AF' does not match
> > > >>> 'Login-User' in
> > > >>> request
> > > >>> Thu Dec 12 09:18:48 2002: DEBUG: Query is: select MACADDRESS,
> > > >>> REPLYMESSAGE
> > > >>> from macblacklist where MACADDRESS like '00-50-04-E8-B4-AF' and
> > > >>> ACTIVE
> > > >>> =
> > > >>> 'Yes'
> > > >>>
> > > >>> Anyway I think it would be good idea to add a keyword RejectIfFound
> > > >>> to
> > > >>> features for blacklist buliding pruposes.
> > > >>>
> > > >>> Rgds.
> > > >>> Toomas Kärner
> > > >>>
> > > >>> ===
> > > >>> 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.
> > >
> > > --
> > > 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.
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd Unix, 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 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