[RADIATOR] AuthByPolicy - Always do every authentication method

Hugh Irvine hugh at open.com.au
Thu Mar 26 04:27:16 CST 2009


Hello Alex -

Please see my previous post.

regards

Hugh


On 26 Mar 2009, at 19:41, Alex Massover wrote:

> Hi!
>
> Sorry. I ensured that it really does every auth method, but somehow  
> it doesn't log what happens inside the second AuthGROUP. Only 2 lines:
>
> Thu Mar 26 08:04:50 2009: DEBUG: Handling with Radius::AuthGROUP:
> Thu Mar 26 08:04:50 2009: DEBUG: AuthBy GROUP result: ACCEPT,
> Thu Mar 26 08:04:50 2009: DEBUG: Accounting accepted
>
> I'll try to debug the logging.
>
> --
> Best Regards,
> Alex Massover
>
> -----Original Message-----
> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au 
> ] On Behalf Of Alex Massover
> Sent: Thursday, March 26, 2009 10:20 AM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] AuthByPolicy - Always do every  
> authentication method
>
> Hi Hugh!
>
> It really looks like it goes to the second AuthByGROUP, but it  
> doesn't reach AuthByURL inside the group. Here's a full log:
>
> Thu Mar 26 08:04:50 2009: DEBUG: Handling request with Handler  
> 'Realm=DEFAULT'
> Thu Mar 26 08:04:50 2009: DEBUG:  Deleting session for , x.x.x.x, 5060
> Thu Mar 26 08:04:50 2009: DEBUG: Handling with Radius::AuthGROUP:
> Thu Mar 26 08:04:50 2009: DEBUG: Handling with Radius::AuthSQL:
> Thu Mar 26 08:04:50 2009: DEBUG: Handling accounting with  
> Radius::AuthSQL
> Thu Mar 26 08:04:50 2009: DEBUG: do query is: 'insert into RATEDCDR  
> (AcctSessionId 
> ,AcctStatusType 
> ,CalledStationId 
> ,CallingStationId 
> ,ConnectInfo 
> ,EventTimestamp 
> ,NASIPAddress 
> ,SIPTOTAG,ServiceType,SipFromTag,SipMethod,SipResponseCode) values  
> ('MjcxYjQyMTg2MjEwMmM2YWNlNzIwZjlmN2VkYjczM2U 
> .','Stop','test','xxxxxxxxx','sip:test at 172.50.10.45:27510;transport=udp',1238054689,'x.x.x.x','3447043391-77604','Sip-Session','096b2e07','Bye',200)' 
> :
> Thu Mar 26 08:04:50 2009: DEBUG: Handling with Radius::AuthGROUP:
> Thu Mar 26 08:04:50 2009: DEBUG: AuthBy GROUP result: ACCEPT,
> Thu Mar 26 08:04:50 2009: DEBUG: Accounting accepted
> Thu Mar 26 08:04:50 2009: DEBUG: Packet dump:
>
> Looks like the second AuthByGROUP return immediately ACCEPT without  
> even trying AuthByURLs inside.
>
> Even more simple configuration:
>
> <AuthBy GROUP>
> AuthByPolicy Every
>        <AuthBy SQL>
>        </AuthBy>
>                <AuthBy URL>
>                </AuthBy>
> </AuthBy>
>
> Produce exactly the same log:
>
> Thu Mar 26 08:16:04 2009: DEBUG: Handling with Radius::AuthGROUP:
> Thu Mar 26 08:16:04 2009: DEBUG: Handling with Radius::AuthSQL:
> Thu Mar 26 08:16:04 2009: DEBUG: Handling accounting with  
> Radius::AuthSQL
> Thu Mar 26 08:16:04 2009: DEBUG: do query is: 'insert into RATEDCDR  
> (AcctSessionId 
> ,AcctStatusType 
> ,CalledStationId 
> ,CallingStationId 
> ,ConnectInfo 
> ,EventTimestamp 
> ,NASIPAddress 
> ,SIPTOTAG,ServiceType,SipFromTag,SipMethod,SipResponseCode) values ...
> Thu Mar 26 08:16:04 2009: DEBUG: AuthBy GROUP result: ACCEPT,
> Thu Mar 26 08:16:04 2009: DEBUG: Accounting accepted
> Thu Mar 26 08:16:04 2009: DEBUG: Packet dump:
>
> Looks like "AuthByPolicy Every" doesn't do every auth method like it  
> supposed to.
>
> --
> Best Regards,
> Alex Massover
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Wednesday, March 25, 2009 11:19 PM
> To: Alex Massover
> Cc: radiator at open.com.au
> Subject: Re: [RADIATOR] AuthByPolicy - Always do every  
> authentication method
>
>
> Hello Alex -
>
> I don't think there is anything wrong with your configuration - the
> debug shows you are doing the first AuthBy GROUP and the second AuthBy
> GROUP.
>
> However, what you are looking at is an accounting request, not an
> authentication request.
>
> regards
>
> Hugh
>
>
> On 25 Mar 2009, at 23:50, Alex Massover wrote:
>
>> Hi!
>>
>> I'm working with accounting and trying to log every request to SQL
>> prior to sending it to application server.
>>
>> Docs state for AuthByPolicy:
>> "- anything else
>> Always do every authentication method. Returns the result of the
>> last one."
>>
>> And this is exactly what I need, i.e. always do SQL and after send
>> it to application server and return the result of application server.
>>
>> Here what I have:
>>
>> cat radius.cfg | grep AuthBy
>>
>> <AuthBy GROUP>
>> AuthByPolicy Every
>>       <AuthBy SQL>
>>       </AuthBy>
>>       <AuthBy GROUP>
>>       AuthByPolicy ContinueUntilAccept
>>                       <AuthBy URL>
>>                       </AuthBy>
>>                       <AuthBy URL>
>>                       </AuthBy>
>>                       <AuthBy URL>
>>                       </AuthBy>
>>               <AuthBy INTERNAL>
>>                       </AuthBy>
>>       </AuthBy>
>> </AuthBy>
>>
>> But the requests never continue beyond the SQL:
>>
>> Wed Mar 25 11:56:16 2009: DEBUG: Handling with Radius::AuthGROUP:
>> Wed Mar 25 11:56:16 2009: DEBUG: Handling with Radius::AuthSQL:
>> Wed Mar 25 11:56:16 2009: DEBUG: Handling accounting with
>> Radius::AuthSQL
>> ...
>> Wed Mar 25 11:56:16 2009: DEBUG: Handling with Radius::AuthGROUP:
>> Wed Mar 25 11:56:16 2009: DEBUG: AuthBy GROUP result: ACCEPT,
>> Wed Mar 25 11:56:16 2009: DEBUG: Accounting accepted
>>
>>
>> What can be wrong with my configuration please?
>>
>> --
>> Best Regards,
>> Alex Massover
>>
>>
>>
>>
>> This mail was sent via Mail-SeCure System.
>>
>>
>>
>> _______________________________________________
>> 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.
>
>
>
>
>
> This mail was received via Mail-SeCure System.
>
>
>
>
>
> This mail was sent via Mail-SeCure System.
>
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> This mail was received via Mail-SeCure System.
>
>
>
>
>
> This mail was sent via Mail-SeCure System.
>
>
>
> _______________________________________________
> 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