(RADIATOR) RE: Defining different hosts for authentication an d accounting in the same handler

Hugh Irvine hugh at open.com.au
Wed May 25 17:38:06 CDT 2005


Hello Michael -

For what you show below it would probably be better to use separate  
Handlers as has already been suggested:


<Handler Request-Type = Accounting-Request, Realm = blah>
         # deal with accounting
         <AuthBy RADIUS>
             IgnoreAuthentication
             ...
             <Host acctserver>
                 AcctPort    1813
                 Secret    blah
             </Host>
         </AuthBy>
</Handler>

<Handler Realm = blah>
         # deal with authentication

     <AuthBy GROUP>
         AuthByPolicy    ContinueWhileAccept

         <AuthBy Custom>
             ...
         </AuthBy>

         <AuthBy RADIUS>
             IgnoreAccounting
             ...
             <Host authserver>
                 AuthPort    1812
                 Secret    blah
             </Host>
         </AuthBy>

     </AuthBy>

</Handler>


The reason for this is due to the fact that the AuthBy RADIUS clause  
operates asynchronously and always immediately returns Ignore, hence  
you usually need to have the AuthBy RADIUS clause last in any group  
so that the ultimate response from the proxy is the final response  
from the sequence.

I also generally find it easier to understand what is going on with  
Handlers structured as above.

regards

Hugh



On 26 May 2005, at 05:41, Michael Harsh wrote:

> Thank you everyone who replied.
>
> Hugh, why does the Accounting AuthBy need to come first?
>
> Also, I am already using an AuthByPolicy, ContinueWhileAccept, due  
> to a
> custom AuthBy. Here is how my config looks:
>
> <Handler RealmId=blah>
>     ...
>     <AuthBy GROUP>
>         AuthByPolicy    ContinueWhileAccept
>
>         <AuthBy Custom>
>             ...
>         </AuthBy>
>
>         <AuthBy RADIUS>
>             IgnoreAccounting
>             ...
>             <Host authserver>
>                 AuthPort    1812
>                 Secret    blah
>             </Host>
>         </AuthBy>
>
>         <AuthBy RADIUS>
>             IgnoreAuthentication
>             ...
>             <Host acctserver>
>                 AcctPort    1813
>                 Secret    blah
>             </Host>
>         </AuthBy>
>     </AuthBy>
> </Handler>
>
> Is having the Accounting AuthBy come first still pertinent?
>
> Thanks,
> Mike
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Tuesday, May 24, 2005 5:38 PM
> To: Michael Harsh
> Cc: 'radiator at open.com.au'
> Subject: Re: (RADIATOR) RE: Defining different hosts for  
> authentication and
> accounting in the same handler
>
>
>
> Hello Michael -
>
> Correct - you should have one AuthBy RADIUS to forward authentication
> to one host and another AuthBy RADIUS clause to forward the
> accounting to another host. You should use AuthByPolicy
> ContinueAlways and the accounting should be first:
>
>          AuthByPolicy ContinueAlways
>
>          <AuthBy RADIUS>
>                  # do accounting
>                  .....
>          </AuthBy>
>
>          <AuthBy RADIUS>
>                  # do authentication
>                  .....
>          </AuthBy>
>
>
> regards
>
> Hugh
>
>
> On 25 May 2005, at 06:59, Michael Harsh wrote:
>
>
>> So far, I've come up with using multiple AuthBy Radius clauses
>> within one
>> handler and specifying the IgnoreAuthentication/Accounting and
>> different
>> hosts.
>>
>> -----Original Message-----
>> From: Michael Harsh
>> Sent: Tuesday, May 24, 2005 2:57 PM
>> To: radiator at open.com.au
>> Subject: Defining different hosts for authentication and accounting
>> in the
>> same handler
>>
>>
>> Hello,
>>
>> I'm wondering if there is another way to specify how to forward
>> authentication requests and accounting requests to different hosts
>> besides
>> defining in the Handler Request-Type or the IgnoreAuthentication/
>> Accounting.
>>
>> My handlers specify realms and within those realms I need to send to
>> separate Radius servers for authentication and accounting. So, I
>> can not use
>> a Request-Type in a Handler clause. And, IgnoreAthentication or
>> IgnoreAccounting does not work within a Host clause where I need it.
>>
>> What other options do I have?
>>
>> Thanks,
>> Mike
>>
>> --
>> 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.


More information about the radiator mailing list