(RADIATOR) Bug?
Toomas Kärner
tomkar at estpak.ee
Wed Dec 18 01:41:52 CST 2002
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.
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.
>
===
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