(RADIATOR) Rejecting Caller-ID from SQL without auth from SQL

Viraj Alankar valankar at ifxcorp.com
Fri Feb 15 08:38:37 CST 2002


On Fri, Feb 15, 2002 at 10:45:53AM +1100, Hugh Irvine wrote:
> 
> Hello Viraj -
> 
> Could you do the following please?
> 
> 1. change the "NoDefaultIfFound" to "AcceptIfMissing"
> 
> 2. remove the "DEFAULT Auth-Type = Accept" line from the 
> VE_Check_CallerID.users file
> 
> Like this:
> 
> ......
> 
> <AuthBy FILE>
>         Identifier VE_Check_CallerID
>         Filename        %D/VE_Check_CallerID.users
>         AcceptIfMissing
> </AuthBy>
> 
> ......
> 
> VE_Check_CallerID.users file looks like:
> 
> # DEFAULT entries to check blacklist
> 
> DEFAULT Auth-Type = VE_CallerID
> 

Hugh,

I've made the changes but this time the test user is accepted even when a
blacklisted caller ID is in the table:

Fri Feb 15 09:24:59 2002: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32782 ....
Code:       Access-Request
Identifier: 254
Authentic:  1234567890123456
Attributes:
        User-Name = "test at test.com"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "02122122320000"
        NAS-Port-Type = Async
        User-Password = "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"

Fri Feb 15 09:24:59 2002: DEBUG: Check if Handler  should be used to handle this request
Fri Feb 15 09:24:59 2002: DEBUG: Handling request with Handler ''
Fri Feb 15 09:24:59 2002: DEBUG:  Deleting session for test at test.com, 203.63.154.1, 1234
Fri Feb 15 09:24:59 2002: DEBUG: Handling with Radius::AuthFILE: VE_Check_CallerID
Fri Feb 15 09:24:59 2002: DEBUG: Radius::AuthFILE looks for match with test at test.com
Fri Feb 15 09:24:59 2002: ERR: Attribute number 79 is not defined in your dictionary
Fri Feb 15 09:24:59 2002: DEBUG: Radius::AuthFILE ACCEPT:
Fri Feb 15 09:24:59 2002: DEBUG: Handling with Radius::AuthFILE: Users_File
Fri Feb 15 09:24:59 2002: DEBUG: Radius::AuthFILE looks for match with test at test.com
Fri Feb 15 09:24:59 2002: DEBUG: Radius::AuthFILE ACCEPT:
Fri Feb 15 09:24:59 2002: DEBUG: Access accepted for test at test.com
Fri Feb 15 09:24:59 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782 ....
Code:       Access-Accept
Identifier: 254
Authentic:  1234567890123456
Attributes:

02122122320000 is in our 've' table. But in this case it did not even execute
the SQL query. Here is the changed config to clarify:

<AuthBy SQL>
        Identifier VE_CallerID

        DBSource ...
        DBAuth callerid

        AuthSelect select "Reject" from ve where callerid = '%{Calling-Station-Id}'
        AuthColumnDef 0, Auth-Type, check
        AccountingTable
</AuthBy>

<AuthBy FILE>
        Identifier VE_Check_CallerID
        Filename        %D/VE_Check_CallerID.users
        AcceptIfMissing
</AuthBy>

<AuthBy FILE>
        Identifier Users_File
        Filename        %D/users
</AuthBy>

<Handler>
        AuthByPolicy ContinueWhileAccept
        AuthBy VE_Check_CallerID
        AuthBy Users_File
</Handler>

VE_Check_CallerID.users file has:

# DEFAULT entries to check blacklist

DEFAULT Auth-Type = VE_CallerID

users file has:

test at test.com

Note that I also added '' in the select to force string comparison instead of
numeric.

Now I was able to get it working with the following config. However, it
appears the select query is still called twice when the callerid doesn't exist
in the table. Basically in this config I took out the options in
VE_Check_CallerID.

<AuthBy FILE>
        Identifier VE_Check_CallerID
        Filename        %D/VE_Check_CallerID.users
</AuthBy>

<AuthBy FILE>
        Identifier Users_File
        Filename        %D/users
</AuthBy>

<Handler>
        AuthByPolicy ContinueWhileAccept
        AuthBy VE_Check_CallerID
        AuthBy Users_File
</Handler>

VE_Check_CallerID.users has:

# DEFAULT entries to check blacklist

DEFAULT Auth-Type = VE_CallerID

DEFAULT Auth-Type = Accept

In a test case where the caller ID exists in the table, everything looks fine:

Fri Feb 15 09:33:47 2002: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32782 ....
Code:       Access-Request
Identifier: 17
Authentic:  1234567890123456
Attributes:
        User-Name = "test at test.com"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "02122122320000"
        NAS-Port-Type = Async
        User-Password = "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"

Fri Feb 15 09:33:47 2002: DEBUG: Check if Handler  should be used to handle this request
Fri Feb 15 09:33:47 2002: DEBUG: Handling request with Handler ''
Fri Feb 15 09:33:47 2002: DEBUG:  Deleting session for test at test.com, 203.63.154.1, 1234
Fri Feb 15 09:33:47 2002: DEBUG: Handling with Radius::AuthFILE: VE_Check_CallerID
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE looks for match with test at test.com
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Fri Feb 15 09:33:47 2002: ERR: Attribute number 79 is not defined in your dictionary
Fri Feb 15 09:33:47 2002: DEBUG: Handling with Radius::AuthSQL
Fri Feb 15 09:33:47 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
Fri Feb 15 09:33:47 2002: DEBUG: Query is: select "Reject" from ve where callerid = '02122122320000'

Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthSQL looks for match with test at test.com
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthSQL REJECT_IMMEDIATE: Rejected explicitly by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: DEBUG: Radius::AuthFILE REJECT_IMMEDIATE: Rejected explicitly by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: INFO: Access rejected for test at test.com: Rejected explicitly by Auth-Type=Reject
Fri Feb 15 09:33:47 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782 ....
Code:       Access-Reject
Identifier: 17
Authentic:  1234567890123456
Attributes:
        Reply-Message = "Request Denied"

But in a test where the callerid does NOT exist in the table, it still works
properly but the query appears to be executed twice:

Fri Feb 15 09:36:48 2002: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32782 ....
Code:       Access-Request
Identifier: 198
Authentic:  1234567890123456
Attributes:
        User-Name = "test at test.com"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port-Type = Async
        User-Password = "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"

Fri Feb 15 09:36:48 2002: DEBUG: Check if Handler  should be used to handle this request
Fri Feb 15 09:36:48 2002: DEBUG: Handling request with Handler ''
Fri Feb 15 09:36:48 2002: DEBUG:  Deleting session for test at test.com, 203.63.154.1, 1234
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthFILE: VE_Check_CallerID
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with test at test.com
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Fri Feb 15 09:36:48 2002: ERR: Attribute number 79 is not defined in your dictionary
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthSQL
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
Fri Feb 15 09:36:48 2002: DEBUG: Query is: select "Reject" from ve where callerid = '987654321'

Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthSQL looks for match with test at test.com
Fri Feb 15 09:36:48 2002: DEBUG: Query is: select "Reject" from ve where callerid = '987654321'

Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE REJECT: No such user
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT1
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE ACCEPT: Accept explicitly by Auth-Type=Accept
Fri Feb 15 09:36:48 2002: DEBUG: Handling with Radius::AuthFILE: Users_File
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE looks for match with test at test.com
Fri Feb 15 09:36:48 2002: DEBUG: Radius::AuthFILE ACCEPT:
Fri Feb 15 09:36:48 2002: DEBUG: Access accepted for test at test.com
Fri Feb 15 09:36:48 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32782 ....
Code:       Access-Accept
Identifier: 198
Authentic:  1234567890123456
Attributes:

Any ideas?

Viraj.

> On Fri, 15 Feb 2002 02:52, Viraj Alankar wrote:
> > On Thu, Feb 14, 2002 at 11:01:08AM +1100, Hugh Irvine wrote:
> > > Hello Viraj -
> > >
> > > You have to do this with different AuthBy clauses, something like this:
> > >
> > > # define AuthBy clauses
> > >
> > > <AuthBy SQL>
> > > 	Identifier CheckNumber
> > > 	.....
> > > 	AuthSelect select ACTION from BLACKLIST \
> > > 		where NUMBER = %{Calling-Station-Id}
> > > 	AccountingTable
> > > </AuthBy>
> > >
> > > <AuthBy FILE>
> > > 	Identifier CheckBlacklist
> > > 	Filename %D/blacklist
> > > 	NoDefaultIfFound
> > > </AuthBy>
> > >
> > > <AuthBy FILE>
> > > 	Identifier YourNormalAuthBy
> > > 	Filename %D/users
> > > 	.....
> > > </AuthBy>
> > >
> > > # define Realms or Handlers
> > >
> > > <Realm ...>
> > > 	AuthByPolicy ContinueWhileAccept
> > > 	AuthBy CheckBlacklist
> > > 	AuthBy YourNormalAuthBy
> > > 	.....
> > > </Realm>
> > >
> > >
> > > The BLACKLIST table in the database would have the list of numbers in the
> > > NUMBER column and "Auth-Type = Reject" in the ACTION column.
> > >
> > >
> > > The file %D/blacklist would contain this:
> > >
> > > # DEFAULT entries to check blacklist
> > >
> > > DEFAULT  Auth-Type = CheckNumber
> > >
> > > DEFAULT  Auth-Type = Accept
> >
> > Hello Hugh,
> >
> > This makes sense, however I seem to have some trouble setting this up.
> > First of all I cannot change the blacklist table in my case, but I think it
> > can be worked around. Here is what I have:
> >
> > In MySQL, we have a table 've' that looks like this:
> >
> > mysql> desc ve;
> > +-----------+---------------+------+-----+---------+-------+
> >
> > | Field     | Type          | Null | Key | Default | Extra |
> >
> > +-----------+---------------+------+-----+---------+-------+
> >
> > | callerid  | varchar(80)   |      | PRI |         |       |
> > | comment   | varchar(80)   | YES  |     | NULL    |       |
> > | timestamp | timestamp(14) | YES  |     | NULL    |       |
> >
> > +-----------+---------------+------+-----+---------+-------+
> >
> > Which is basically the blacklist table. For radiator I did:
> >
> > <AuthBy SQL>
> >         Identifier VE_CallerID
> >
> >         DBSource ...
> >
> >         AuthSelect select "Reject" from ve where callerid =
> > %{Calling-Station-Id} AuthColumnDef 0, Auth-Type, check
> >         AccountingTable
> > </AuthBy>
> >
> > <AuthBy FILE>
> >         Identifier VE_Check_CallerID
> >         Filename        %D/VE_Check_CallerID.users
> >         NoDefaultIfFound
> > </AuthBy>
> >
> > <AuthBy FILE>
> >         Identifier Users_File
> >         Filename        %D/users
> > </AuthBy>
> >
> > <Handler>
> >         AuthByPolicy ContinueWhileAccept
> >         AuthBy VE_Check_CallerID
> >         AuthBy Users_File
> > </Handler>
> >
> > VE_Check_CallerID.users file looks like:
> >
> > # DEFAULT entries to check blacklist
> >
> > DEFAULT Auth-Type = VE_CallerID
> >
> > DEFAULT Auth-Type = Accept
> >
> > users file looks like:
> >
> > test at test.com
> >
> > Now I did a radpwtst with a calling-station-id that did not exist in the
> > table:
> >
> > radpwtst ... -noacct -user test at test.com -password test
> >
> > But it is rejected for some reason. The logfile looks like this:
> >
> > Thu Feb 14 10:46:27 2002: INFO: Server started: Radiator 2.19 on
> > tutraddev.ifxcorp.com Thu Feb 14 10:46:40 2002: DEBUG: Packet dump:
> > *** Received from 127.0.0.1 port 32782 ....
> > Code:       Access-Request
> > Identifier: 100
> > Authentic:  1234567890123456
> > Attributes:
> >         User-Name = "test at test.com"
> >         Service-Type = Framed-User
> >         NAS-IP-Address = 203.63.154.1
> >         NAS-Port = 1234
> >         Called-Station-Id = "123456789"
> >         Calling-Station-Id = "987654321"
> >         NAS-Port-Type = Async
> >         User-Password =
> > "<215>f<171><11><174><150><128>>x<243>f<245>>I$<157>"
> >
> > Thu Feb 14 10:46:40 2002: DEBUG: Check if Handler  should be used to handle
> > this request Thu Feb 14 10:46:40 2002: DEBUG: Handling request with Handler
> > ''
> > Thu Feb 14 10:46:40 2002: DEBUG:  Deleting session for test at test.com,
> > 203.63.154.1, 1234 Thu Feb 14 10:46:40 2002: DEBUG: Handling with
> > Radius::AuthFILE: VE_Check_CallerID Thu Feb 14 10:46:40 2002: DEBUG:
> > Radius::AuthFILE looks for match with test at test.com Thu Feb 14 10:46:40
> > 2002: DEBUG: Radius::AuthFILE looks for match with DEFAULT Thu Feb 14
> > 10:46:40 2002: ERR: Attribute number 79 is not defined in your dictionary
> > Thu Feb 14 10:46:40 2002: DEBUG: Handling with Radius::AuthSQL
> > Thu Feb 14 10:46:40 2002: DEBUG: Handling with Radius::AuthSQL: VE_CallerID
> > Thu Feb 14 10:46:40 2002: DEBUG: Query is: select "Reject" from ve where
> > callerid = 987654321
> >
> > Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthSQL looks for match with
> > test at test.com Thu Feb 14 10:46:40 2002: DEBUG: Query is: select "Reject"
> > from ve where callerid = 987654321
> >
> > Thu Feb 14 10:46:40 2002: DEBUG: Radius::AuthFILE REJECT: No such user
> > Thu Feb 14 10:46:40 2002: INFO: Access rejected for test at test.com: No such
> > user Thu Feb 14 10:46:40 2002: DEBUG: Packet dump:
> > *** Sending to 127.0.0.1 port 32782 ....
> > Code:       Access-Reject
> > Identifier: 100
> > Authentic:  1234567890123456
> > Attributes:
> >         Reply-Message = "Request Denied"
> >
> > I'm not sure what I'm doing wrong here. First it appears the select query
> > is called twice. Also the 'users' file is never checked. Any ideas?
> >
> > Thanks,
> >
> > Viraj.
> > ===
> > 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