(RADIATOR) - <AuthBy GROUP> and <AcctCoulmnDef> relationship

[Hugh Irvine]

Hi Albert -

The first AuthBy SQL will catch all the accounting requests.

regards

Hugh


On 12 Oct 2005, at 04:59, Albert Lai wrote:

> hi Hugh,
>
> i have a few group of users and they login without a realm.  
> However, in the
> user profile in the SQL database, I have a parameter defined to
> differentiate the type of users in the request. Username is also  
> unique. So
> there won't be a situation whereby the same username appear on  
> different
> user categories.
>
> With each <AuthBy SQL>, I have a Authselect statement to match the  
> username
> and its type to determine whether it shld be authenticated under the
> respective <AuthBy SQL> defination.
>
> Something like that:
>
> AuthSelect SELECT password,expiry_date,timeleft FROM AccountUser WHERE
> username=%0 AND user_type=%{GlobalVar:usertype1}
>
> If the user type does not match the first <AuthBy SQL> defination,  
> then it
> will goes into the new <AuthBy SQL> defination and so on.
>
> I will need accounting info to be saved for all types of users. So my
> question is whether I need to include AccountingTable and  
> AcctColumnDef
> statements in all <AuthBy SQL> definations or the first one will  
> cover for
> all?
>
> Thanks.
>
> Albert Lai
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: 11 October 2005 18:28
> To: Albert Lai
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) - <AuthBy GROUP> and <AcctCoulmnDef>
> relationship
>
>
>
> Hello Albert -
>
> What exactly are you wanting to do?
>
> If you want the accounting to only go to the first AuthBy SQL what
> you show below will work.
>
> Radiator will not keep track of which AuthBy SQL clause is used for
> the authentication.
>
> regards
>
> Hugh
>
>
> On 11 Oct 2005, at 13:11, Albert Lai wrote:
>
>
>> hi,
>>
>> I am planning to use <AuthBy GROUP> feature to create multiple
>> <AuthBy xxx>
>> methods for the Radiator to fall-through the various authentication
>> method.
>> Below is my sample config overall structure:
>>
>> <Realm DEFAULT>
>>     MaxSessions 1
>>     RejectHasReason
>>
>>     <AuthBy GROUP>
>>         AuthByPolicy ContinueUntilAccept
>>
>>         <AuthBy SQL>
>>                 -
>>                 -
>>             AuthColumnDef   xxxxxxxxxx
>>             AuthColumnDef   xxxxxxxxxx
>>                 -
>>                 -
>>            AccountingTable xxxx
>>             AcctColumnDef   xxxxx
>>             AcctColumnDef   xxxxx
>>
>>     </AuthBy SQL>
>>
>>       <AuthBy SQL>
>>                 -
>>                 -
>>             AuthColumnDef   xxxxxxxxxx
>>             AuthColumnDef   xxxxxxxxxx
>>
>>     </AuthBy SQL>
>>
>>        <AuthBy SQL>
>>                 -
>>                 -
>>             AuthColumnDef   xxxxxxxxxx
>>             AuthColumnDef   xxxxxxxxxx
>>
>>     </AuthBy SQL>
>>
>> </AuthBy>
>> </Realm>
>>
>> Questions:
>>
>> 1. I have only include AcctColumnDef statements in the first
>> <AuthBy SQL>
>> defination. If the user is authenticated by the other <AuthBy SQL>
>> definations other than the first one, will the accounting logs be
>> saved to
>> the database as well? Or do I need to input the AcctColumnDef and
>> AccountingTable statements in all <AuthBy SQL> defined?
>>
>> 2. When the radiator received a accounting start and stop request,
>> will it
>> goes through the <AuthBy SQL> definations sequentially or it is
>> able to keep
>> track of which <AuthBy SQL> defination the user was previously
>> autheticated
>> successfully with?
>>
>> Thanks.
>>
>> Albert Lai
>>
>> --
>> 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.
>>
>>
>
>
> 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?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> 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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.


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