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

David J Craigon david at craigon.co.uk
Fri Apr 24 11:15:56 CDT 2009


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.
>
>
>



More information about the radiator mailing list