Hello Andrew -
On Mon, 07 Feb 2000, Andrew Pollock wrote:
>
> What I want to do is, by default proxy the authentication request to another
> RADIUS server. In the event of not receiving a response from that RADIUS
> server, authenticate the request from a text file (in UNIX password format)
> locally.
>
> So, under normal circumstances, a request should be proxied and the AuthBy
> UNIX never touched, and in the event of the RADIUS server that the requests
> are being proxied to failing, it authenticates the requests locally.
>
> What's currently happening is the request seems to be being dispatched to
> both authenticators in parallel, instead of in series.
>
Unfortunately this whole scenario is fraught with danger, due to the nature of
the radius protocol and the nature of NAS implementations and also of PC dialer
implementations. The problem is one of radius design, being based on UDP as it
is. Because packets can get lost, radius is designed with timeouts: the PC
probably has a dialer timeout of 30 seconds and your NAS equipment is probably
configurable with regards to delay and number of retries. All well and good you
say, but therein lies the problem with what you are trying to do.
Radiator is normally designed to return immediately from an AuthBy RADIUS, as
you have discovered. This is because of performance reasons and trying to keep
things moving inside the server. The one thing Radiator tries very hard not to
do is "stop and wait", which is what you are asking it to do in your scenario.
The only way to do what you require is to configure the AuthBy RADIUS with two
additional parameters: "Synchronous" and "Fork". Now I am going to do some
testing here with these parameters, and I strongly suggest you do the same
before you put it into production.
Adding the "Synchronous" flag to AuthBy RADIUS will cause it to stop and wait
for the response (or not) of the remote radius server. Note that this is
implemented in a patch to AuthRADIUS.pm:
http://www.open.com.au/radiator/downloads/patches-2.14.1/
1/9/99 Experimental version of AuthBy RADIUS implements the new
Synchronous parameter, which will cause the AuthBy RADIUS to block
until a reply is received from the remote radius server (or it times out).
It will only continue to process following AuthBy clauses after the
remote has responded (or timed out).
There can be a serious performace hit with this, since incoming requests
will not be handled until the reply (or timeout) is received from the
remote radius server.
You might consider using the Fork flag to reduce the effect of this, at
the cost of increased memory usage.
In any case, use it with caution.
Let us know if there are any problems.
Download the new AuthRADIUS.pm from here.
As mentioned above, to avoid having Radiator wait for every request, you will
have to add the "Fork" parameter to the AuthBy RADIUS, which will cause the
entire Radiator process to fork to service each proxy radius request. Using
this flag obviously entails *large* system overheads, as each proxied request
will cause a complete copy of Perl and the Radiator process to be copied in
memory.
So - I've given you enough rope I think - use it with extreme caution and
please let us know how you get on. Note that in our opinion this only has any
hope of working on a fairly lightly loaded Radiator host.
hth
Hugh
ps - the only real way of implementing this correctly is with a threaded
version of Perl and Radiator, which would be able to run each request in a
seperate thread....
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
