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 [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
To: "Toomas K�rner" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
