(RADIATOR) AuthBy Group, AuthBy Radius and DefaultReply problem

Christophe Lestienne Christophe.Lestienne at um.be
Mon May 7 22:35:35 CDT 2001


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Christophe.Lestienne.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: Card for Christophe Lestienne
URL: <http://www.open.com.au/pipermail/radiator/attachments/20010508/7d366bd7/attachment.vcf>


More information about the radiator mailing list