(RADIATOR) Bug?
Hugh Irvine
hugh at open.com.au
Fri Dec 13 15:50:19 CST 2002
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.
More information about the radiator
mailing list