(RADIATOR) Bug?
Surajh Surjoo [ MTN Sandhurst ]
Surajh.Surjoo at mtn.co.za
Wed Dec 18 03:15:50 CST 2002
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!
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.
===
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