Hi Andrew,
You can catch the case where its a realm the central server does not know about
by adding a
<Realm DEFAULT>
</Realm>
to your config, which will reject any requests from realms not otherwise
handled.
AS for rejecting if the certral server does not reply (due connectivity
problems) Im not sure that changing the behaviour will gain you anything? From
the users point of view it would be the same: a delay, followed by
disconnection.
In any case, there is no way (without changing the code) to send a reject if
the retransmits to the central server time out.
On Jan 26, 7:50pm, Andrew Pollock wrote:
> Subject: (RADIATOR) Rejecting rather than Ignoring requests
> Hi,
>
> I am trying to configure a roaming RADIUS setup whereby there are a number
> of regional RADIUS servers and a centralised one.
>
> When the regional RADIUS servers strike a realm they don't know about (which
> is pretty much any realm), they proxy the request to the central RADIUS
> server (which knows about many realms) when thens proxies the request to the
> appropriate RADIUS server for final authentication.
>
> This is working fine under good conditions, but under conditions when the
> central RADIUS server is unreachable (and therefore the regional RADIUS
> server ignores the request), or the central RADIUS server doesn't know about
> the realm (and ignores the request), the poor old NAS never gets a reply
> back, decides that the RADIUS server is a dud and swaps to it's backup
> RADIUS server.
>
> I'd actually prefer that an Access-Reject get sent back instead of just
> ignoring the request.
>
> I thought I could achieve this by using two AuthBy clauses in a Handler, but
> instead of only using the second AuthBy clause when the first is ignored
> (which I thought was the default AuthByPolicy behaviour) it seems to be
> running both in parallel. As the second AuthBy clause sends a reject, a
> reject is being sent back to the NAS all the time, which is obviously not
> the desired effect.
>
> Here's a configuration snippet:
>
> === SNIPPET ===
> # Specific realm handlers are above this
>
> <Handler Realm=/.*/>
> AcctLogFileName /var/log/radacct/remote/%R/detail
> AuthByPolicy ContinueWhileIgnore
> <AuthBy RADIUS>
> Host 203.x.y.z
> Host 203.w.x.y
> Secret NotTelling
> AuthPort 1645
> AcctPort 1646
> Retries 3
> RetryTimeout 5
> </AuthBy>
> <AuthBy FILE>
> Filename /usr/local/etc/raddb/rackoff
> </AuthBy>
> </Handler>
> === END SNIPPET ===
>
> /usr/local/etc/raddb/rackoff simply contains:
>
> DEFAULT Auth-Type = Reject
>
> Any suggestions would be appreciated.
>
> Andrew
>
>
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Andrew Pollock
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
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.
