(RADIATOR) AuthBy Group, AuthBy Radius and DefaultReply problem

[Hugh Irvine]

Salut Christophe -

The problem you describe below is due to the implementation of the AuthBy 
RADIUS clause, which is asynchronous and returns immediately with a status of 
Ignore. Hence you cannot set up your configuration file as you show below 
because the ContinueWhileAccept will not operate correctly.

The best thing to do in this situation is to use a ReplyHook in the AuthBy 
RADIUS clause which will fire when the reply comes in from the ACE server. 
There is an example of how to do this in the file "goodies/hooks.txt".

If you need any help just let me know.

regards

Hugh


On Tuesday 08 May 2001 13:35, Christophe Lestienne wrote:

> > Hello!,
>
> I have a problem with a Radiator 2.17.1 running on Perl 5.5.3 on SunOS
> 5.8 (although I don't the problem is version related).
>
> For some of our users, we have to chain authenticators in order to
> retrieve their authorization from a LDAP server while their
> authentication is done through an ACE server.
>
> So my configuration looks like
>
> <Realm Test>
>   RewriteUsername s/^([^@]+).*/$1/
>   <AuthBy GROUP>
>     AuthByPolicy ContinueWhileAccept
>     AuthBy AceServer
>     AuthBy Ldap
>     DefaultReply Service-Type = Framed-User, Framed-Protocol = PPP,
> Framed-MTU = 1500
>   </AuthBy>
>   RejectHasReason
> </Realm>
>
> Basically, the AceServer is queried through their Radius implementation,
> and I only except an Accept/Reject, no extra configuration to be done in
> the AceServer. Now, the idea was to be able to configure a field in the
> LDAP for Radius replies (such as service-type) but still have a default
> user configuration stored in the AuthBy GROUP statement (hence the
> DefaultReply).
>
> Now all the stuff works until the AuthBy AceServer (actually a Radius
> one) is activated. When I receive an Access-Accept from the Ace Radius
> server, the answer is sent back to the NAS server and not further
> processed by the AuthBy GROUP statement.
>
> I'm quite sure it is related to the asynchronous character (UDP) of the
> communication with the other Radius server. I have had a look at the
> code and the doc and understand the Synchronous approach could be a
> solution. Even if I don't have to handle a lot of requests, I guess the
> server enters a blocking call while waiting for the reply from the Ace
> Server, and the later tends to need about 4 seconds to compute the
> token...
>
> So what's the best approach
> - sync in the AuthBy Radius while forking to remain alive for the others
>
> - use a TCP connection (Tacacs+) to the ACE? And fork too?
> - other suggestions
>
> I would like to hear other experience of the integration of the Radiator
> with the SecurID env
>
> Thanks for your help
>
> Regards
>
> Christophe

----------------------------------------
Content-Type: text/x-vcard; charset="us-ascii"; 
name="Christophe.Lestienne.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Christophe Lestienne
----------------------------------------

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.