(RADIATOR) Bug?
Mike McCauley
mikem at open.com.au
Wed Dec 18 02:32:02 CST 2002
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