(RADIATOR) Bug?

Fri Dec 13 05:26:15 CST 2002

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.