Dropping requests when no authentication possible

[Chris Phillips]

On Thu, Mar 12, 2009 at 5:07 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > Is there any way to force a logic whereby if the ldap module fails, it
> would
> > drop the RADIUS request on the floor, to make it look like a service
> failure
> > to the client? Kinda wrecks our resiliency model if not! We're only using
> a
> > single ldap server per box, but even if we were using other ldap servers
> on
> > other servers, there still is a logic whereby it may be impossible to
> reach
> > any LDAP server whilst another FreeRADIUS box can reach one, but is of a
> > lower order of preference so can't be used.
>
> seems to be a current popular feature. if you read the mialing list archive
> this veyr minth theres a similar case for doing pretty much the same with
> SQL
> (insteda of your ldap).  you could, perhaps not need to do this if you let
> each RADIUS server also talk to each LDAP. you can then configure LDAP
> as a failover/redundant system (see the guides/docs for doing redundant
> LDAP).  so
>
> RADIUS1 - ldap 1, ldap 2, ldap 3
> RADIUS2 - ldap 2, ldap 1, ldap 3
> RADIUS3 - ldap 3, ldap 2, ldap 1
>
> if they can share their LDAP this would be ideal... however, if not, then
> you'll have to use the method mentioned previously on the list - note
> the (fail) and return the fail attribute to the NAS rather than reject.
> if the NAS is good/proper, it'll try the next RADIUS itself.
>

Well they can share the LDAP servers, but if these servers have 2 nics, 1
for RADIUS access and 1 solely for back end access between RADIUS and LDAP,
and this rear network connection fails then this scenario comes back big
style and there's not much ideal about it. Whilst it's no fault specifically
of its own, that RADIUS server is completely useless, and no client device
of mine would try the second ever whilst it's getting nice and polite
REJECT's back.

I'll be checking out that other sql thread, although at the moment it seems
that it's not working for the other guy...

Cheers

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090312/89b1e5c4/attachment.html>