[RADIATOR] FW: Radiator, AuthSQL and always accepting [633444:1281779]

David J Craigon david at craigon.co.uk
Mon Apr 27 08:55:54 CDT 2009


This doesn't appear to work, at least not for me.

Here is my config currently

<Handler Client-Identifier=RedBack>

        # Successful logins
        <AuthBy SQL>
                DBSource        aaaaaaaaaaa
                DBUsername      xxxxx
                DBAuth          yyyyy

                AuthSelect file:"/etc/radiator/redback-query"
                PostAuthSelectHook file:"/etc/radiator/mangle-radius.pl"

        # Note the check part-- this section is for successful passwords
                AuthColumnDef 0, Password, check
                AuthColumnDef 1, Service-Type, reply
                AuthColumnDef 2, Framed-Protocol, reply
                AuthColumnDef 3, Framed-IP-Address, reply
                AuthColumnDef 4, Framed-IP-Netmask, reply
                AuthColumnDef 5, RB-Context-Name, reply
                AuthColumnDef 6, RB-Qos-Policy-Metering, reply
                AuthColumnDef 7, RB-Qos-Policy-Policing, reply
                AuthColumnDef 8, RB-Qos-Policy-Queuing, reply
                AuthColumnDef 10, RB-Client-DNS-Pri, reply
                AuthColumnDef 11 ,RB-Client-DNS-Sec, reply

                FailureBackoffTime      30
        </AuthBy>

        <AuthBy SQL>
                DBSource       aaaaaaaa
                DBUsername      xxxxx
                DBAuth          yyyyy

                AuthSelect file:"/etc/radiator/redback-query"
                PostAuthSelectHook file:"/etc/radiator/mangle-radius.pl"

        # For the wrong password section, ignore the password
                AuthColumnDef 0, Password, reply
                AuthColumnDef 1, Service-Type, reply
                AuthColumnDef 2, Framed-Protocol, reply
                AuthColumnDef 3, Framed-IP-Address, reply
                AuthColumnDef 4, Framed-IP-Netmask, reply
                AuthColumnDef 5, RB-Context-Name, reply
                AuthColumnDef 6, RB-Qos-Policy-Metering, reply
                AuthColumnDef 7, RB-Qos-Policy-Policing, reply
                AuthColumnDef 8, RB-Qos-Policy-Queuing, reply
                AuthColumnDef 10, RB-Client-DNS-Pri, reply
                AuthColumnDef 11 ,RB-Client-DNS-Sec, reply

                FailureBackoffTime      30
        </AuthBy>

        # Add the default settings to all authentication replies
        AuthLog SQLAuthLog
        AuthLog SQLAuthLog2

</Handler>

Now according to your instructions, it should fall through the first
config, and match the second config, which should accept everything.
Looking at my radiator logs, it does indeed run both queries, but
still rejects.

David


2009/4/25 Hugh Irvine <hugh at open.com.au>:
>
> Hello David -
>
> You need to use two AuthBy SQL clauses, the first for normal authentication
> and the second for failures.
>
> Something like this:
>
>
> <Handler Client-Identifier=RedBack>
>
>        # if the first AuthBy fails, try the second
>
>        AuthByPolicy ContinueUntilAccept
>
>       <AuthBy SQL>
>                # do normal authentication
>               DBSource        zzzzzz
>               DBUsername     xxxxx
>               DBAuth          yyyyy
>
>               AuthSelect file:"/etc/radiator/redback-query"
>               AuthColumnDef 0, Password, check
>               AuthColumnDef 1, Service-Type, reply
>               AuthColumnDef 2, Framed-Protocol, reply
>               AuthColumnDef 3, Framed-IP-Address, reply
>               AuthColumnDef 4, Framed-IP-Netmask, reply
>               AuthColumnDef 5, RB-Context-Name, reply
>               AuthColumnDef 6, RB-Qos-Policy-Metering, reply
>               AuthColumnDef 7, RB-Qos-Policy-Policing, reply
>               AuthColumnDef 8, RB-Qos-Policy-Queuing, reply
>               AuthColumnDef 10, RB-Client-DNS-Pri, reply
>               AuthColumnDef 11 ,RB-Client-DNS-Sec, reply
>
>               FailureBackoffTime      30
>       </AuthBy>
>
>       <AuthBy SQL>
>                # do whatever for failure
>               DBSource        zzzzzz
>               DBUsername     xxxxx
>               DBAuth          yyyyy
>
>               AuthSelect ......
>               AuthColumnDef 0, .......
>                ........
>               FailureBackoffTime      30
>       </AuthBy>
>
>       # Add the default settings to all authentication replies
>       AuthLog SQLAuthLog
>       AuthLog SQLAuthLog2
>
> </Handler>
>
>
> hope that helps
>
> regards
>
> Hugh
>
>
> On 25 Apr 2009, at 02:15, David J Craigon wrote:
>
>> This doesn't quite do what I want. Although by taking all of the
>> "check" out, I can get it to ignore the password and always accept, I
>> don't see how I can get it to change attributes based on whether it
>> has passed or failed.
>>
>> Here's what I'm trying at the moment:
>>
>> <Handler Client-Identifier=RedBack>
>>       <AuthBy SQL>
>>               DBSource        zzzzzz
>>               DBUsername     xxxxx
>>               DBAuth          yyyyy
>>
>>               AuthSelect file:"/etc/radiator/redback-query"
>>               AuthColumnDef 0, Password, check
>>               AuthColumnDef 1, Service-Type, reply
>>               AuthColumnDef 2, Framed-Protocol, reply
>>               AuthColumnDef 3, Framed-IP-Address, reply
>>               AuthColumnDef 4, Framed-IP-Netmask, reply
>>               AuthColumnDef 5, RB-Context-Name, reply
>>               AuthColumnDef 6, RB-Qos-Policy-Metering, reply
>>               AuthColumnDef 7, RB-Qos-Policy-Policing, reply
>>               AuthColumnDef 8, RB-Qos-Policy-Queuing, reply
>>               AuthColumnDef 10, RB-Client-DNS-Pri, reply
>>               AuthColumnDef 11 ,RB-Client-DNS-Sec, reply
>>
>>               FailureBackoffTime      30
>>       </AuthBy>
>>
>>       PostAuthHook    sub {if (${$_[2]} == $main::REJECT) {
>> ${$_[2]}=$main::ACCEPT; ${$_[1]}->change_attr("RB-Context-Name",
>> "badpassword"); } }
>>
>>
>>
>>       # Add the default settings to all authentication replies
>>       AuthLog SQLAuthLog
>>       AuthLog SQLAuthLog2
>>
>> </Handler>
>>
>> What I want to achieve is if the password sent in the packet is not
>> valid, I want RB-Context-Name sent to "badpassword". You can see my
>> current attempt with my PostAuthHook. The always accept bit works, but
>> my reply packets are stripped of all of the other attributes-
>>
>>
>> Code:       Access-Accept
>> Identifier: 0
>> Authentic:  <241><227><132><23><2><197>Y)O<223><209><197><134><12>:<213>
>> Attributes:
>>        RB-Context-Name = "badpassword"
>>
>> The other way I could think of is by doing something like this :
>>
>>       <AuthBy SQL>
>>               DBSource        zzzzzz
>>               DBUsername     xxxxx
>>               DBAuth          yyyyy
>>
>>               AuthSelect file:"/etc/radiator/redback-query"
>>               AuthColumnDef 0, Password, reply
>>               AuthColumnDef 1, Service-Type, reply
>>               AuthColumnDef 2, Framed-Protocol, reply
>>               AuthColumnDef 3, Framed-IP-Address, reply
>>               AuthColumnDef 4, Framed-IP-Netmask, reply
>>               AuthColumnDef 5, RB-Context-Name, reply
>>               AuthColumnDef 6, RB-Qos-Policy-Metering, reply
>>               AuthColumnDef 7, RB-Qos-Policy-Policing, reply
>>               AuthColumnDef 8, RB-Qos-Policy-Queuing, reply
>>               AuthColumnDef 10, RB-Client-DNS-Pri, reply
>>               AuthColumnDef 11 ,RB-Client-DNS-Sec, reply
>>
>>               FailureBackoffTime      30
>>       </AuthBy>
>>
>>       PostAuthHook    sub {if (PASSWORD IS WRONG) {
>> ${$_[1]}->change_attr("RB-Context-Name", "badpassword"); } }
>>
>>
>> Trouble is I don't know how to write the  PASSWORD IS WRONG code,
>> since the password is encrypted.
>>
>> Thanks for all your help,
>>
>> David
>>
>> 2009/4/23 Hugh Irvine <hugh at open.com.au>:
>>>
>>> Hello David -
>>>
>>> In that case, just use an AuthSelect and AuthColumnDef's that don't check
>>> the password.
>>>
>>> .....
>>>       <AuthBy SQL>
>>>               # example that doesn't check the password
>>>               .....
>>>               AuthSelect select CHECKATTR, REPLYATTR from SUBSCRIBERS
>>> where
>>> USERNAME = %0
>>>
>>>               AuthColumnDef 0, GENERIC, check
>>>               AuthColumnDef 1, GENERIC, reply
>>>       </AuthBy>
>>> ....
>>>
>>> Is that what you mean?
>>>
>>> See section 5.29.6 (and following) in the Radiator 4.4 reference manual
>>> ("doc/ref.pdf").
>>>
>>> Otherwise you can add a DEFAULT entry to your database with whatever you
>>> require.
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>> On 23 Apr 2009, at 20:43, David J Craigon wrote:
>>>
>>>> AuthBy INTERNAL would work, the trouble is that I've already got all
>>>> my usernames, passwords and so on in a database. Now I could replicate
>>>> all of this functionality by writing DBI scripts into the AuthBy
>>>> INTERNAL hooks, but that seems a bit of wasted effort, especially
>>>> since I've no doubt your code is of a higher standard than I'd be able
>>>> to string together.  I've got a working AuthBy SQL solution at the
>>>> moment.
>>>>
>>>>
>>>> Any other suggestions?
>>>>
>>>> David
>>>>
>>>>>
>>>>> Hello David -
>>>>>
>>>>> You can use an AuthBy INTERNAL:
>>>>>
>>>>> .....
>>>>>
>>>>>      <AuthBy INTERNAL>
>>>>>              AuthResult ACCEPT
>>>>>              AcctResult ACCEPT
>>>>>              AddToReply .......
>>>>>      </AuthBy>
>>>>>
>>>>> .....
>>>>>
>>>>> See section 5.48 in the Radiator 4.4 reference manual ("doc/ref.pdf").
>>>>>
>>>>> regards
>>>>>
>>>>> Hugh
>>>>>
>>>>>
>>>>> On 23 Apr 2009, at 01:48, David Craigon wrote:
>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> We use Radiator for a DSL application. We use AuthSQL.
>>>>>>
>>>>>> I've been asked to implement a system where we accept everyone,
>>>>>> regardless of password. If the user types in the password wrong, we
>>>>>> simply add some other attributes to their Radius Accept packet that
>>>>>> gets our routers to dump the user in a sandbox which only lets them
>>>>>> view a "change your password" page.
>>>>>>
>>>>>> I can think of some ways of trying to achieve this but I thought I'd
>>>>>> ask here to see if this list could give me any advice.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> _______________________________________________
>>>>>> radiator mailing list
>>>>>> radiator at open.com.au
>>>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>>>
>>>>>
>>>>>
>>>>> NB:
>>>>>
>>>>> Have you read the reference manual ("doc/ref.html")?
>>>>> Have you searched the mailing list archive
>>>>> (www.open.com.au/archives/radiator)?
>>>>> Have you had a quick look on Google (www.google.com)?
>>>>> Have you included a copy of your configuration file (no secrets),
>>>>> together with a trace 4 debug showing what is happening?
>>>>> Have you checked the RadiusExpert wiki:
>>>>> http://www.open.com.au/wiki/index.php/Main_Page
>>>>>
>>>>> --
>>>>> Radiator: the most portable, flexible and configurable RADIUS server
>>>>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>>>>> Includes support for reliable RADIUS transport (RadSec),
>>>>> and DIAMETER translation agent.
>>>>> -
>>>>> Nets: internetwork inventory and management - graphical, extensible,
>>>>> flexible with hardware, software, platform and database independence.
>>>>> -
>>>>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>
>>>
>>>
>>> NB:
>>>
>>> Have you read the reference manual ("doc/ref.html")?
>>> Have you searched the mailing list archive
>>> (www.open.com.au/archives/radiator)?
>>> Have you had a quick look on Google (www.google.com)?
>>> Have you included a copy of your configuration file (no secrets),
>>> together with a trace 4 debug showing what is happening?
>>> Have you checked the RadiusExpert wiki:
>>> http://www.open.com.au/wiki/index.php/Main_Page
>>>
>>> --
>>> Radiator: the most portable, flexible and configurable RADIUS server
>>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>>> Includes support for reliable RADIUS transport (RadSec),
>>> and DIAMETER translation agent.
>>> -
>>> Nets: internetwork inventory and management - graphical, extensible,
>>> flexible with hardware, software, platform and database independence.
>>> -
>>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>>
>>>
>>>
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
>



More information about the radiator mailing list