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

Albert Lai albertlai at antlabs.com
Tue Oct 11 20:59:37 CDT 2005


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.


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


More information about the radiator mailing list