[RADIATOR] FW: Radiator, AuthSQL and always accepting [633444:1281779]
Hugh Irvine
hugh at open.com.au
Mon Apr 27 18:47:28 CDT 2009
Hello David -
I don't see the "AuthByPolicy ContinueUntilAccept" in your
configuration file.
It would also be most helpful if you could include a trace 4 debug
showing what is happening.
regards
Hugh
On 27 Apr 2009, at 23:55, David J Craigon wrote:
> 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.
>>
>>
>>
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