Dropping requests when no authentication possible

[Chris Phillips]

On Fri, Mar 13, 2009 at 8:13 AM, Alan DeKok <aland at deployingradius.com>wrote:

> Chris Phillips wrote:
> > I've set up a 2.1.4 server, and working pretty well with authentication
> > against LDAP alone. What I've noticed though is that if the LDAP server
> > is down on the same box then the LDAP module, rightfully, fails. However
> > whilst this leaves the service unable to authenticate the user, it still
> > replies back with a REJECT packet to the client. As such the client
> > switch / router whatever, doesn't try the next server in it's config, as
> > it's had a valid RADIUS response.
>
>   Ah... if both ldap modules fail, then the redundant{} section returns
> fail, and the request stops being processed.
>
> > 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.
>
>   Try:
>
> authorize {
>        ...
>        redundant {
>                redundant {
>                        ldap1
>                        ldap2
>                }
>
>                group {
>                        update control {
>                                Response-Packet-Type = Do-Not-Respond
>                        }
>
>                        ok
>                }
>        }
> }
>
>  That should work better...
>
>  The outer "redundant"  block says:
>
>        try the first "redundant" block.
>        if it fails, try the "group" block
>
>  The inner "redundant" block says:
>
>        try ldap1
>        if it fails, try ldap2
>        if it fails, return fail
>
>  The inner "group" block says:
>
>        update the control list so that the server doesn't respond
>        force an "OK" return code
>
>  I don't have time to try this now... but if it works, we can put a
> sample in the default configuration.
>
>  Alan DeKok.


Thanks Alan, here's where I've ended up so far...

Fri Mar 13 09:57:22 2009 : Error: rlm_ldap: (re)connection attempt failed
Fri Mar 13 09:57:22 2009 : Info: [ldap] search failed
Fri Mar 13 09:57:22 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0

Fri Mar 13 09:57:22 2009 : Info: +++[ldap] returns fail
Fri Mar 13 09:57:22 2009 : Info: +++- entering group  {...}
Fri Mar 13 09:57:22 2009 : Info: ++++[control] returns fail
Fri Mar 13 09:57:22 2009 : Info: ++++[ok] returns ok
Fri Mar 13 09:57:22 2009 : Info: +++- group  returns ok
Fri Mar 13 09:57:22 2009 : Info: ++- policy redundant returns ok
Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type)
configuration found for the request: Rejecting the user
Fri Mar 13 09:57:22 2009 : Info: Failed to authenticate the user.
Fri Mar 13 09:57:22 2009 : Auth: Login incorrect: [fbloggs] (from client
my-switch port 0 cli 10.10.10.10)
Fri Mar 13 09:57:22 2009 : Info: Using Post-Auth-Type Reject
Fri Mar 13 09:57:22 2009 : Info: +- entering group REJECT {...}
Fri Mar 13 09:57:22 2009 : Info: [attr_filter.access_reject]    expand:
%{User-Name} -> fbloggs
Fri Mar 13 09:57:22 2009 : Debug:  attr_filter: Matched entry DEFAULT at
line 11
Fri Mar 13 09:57:22 2009 : Info: ++[attr_filter.access_reject] returns
updated
Fri Mar 13 09:57:22 2009 : Info: Delaying reject of request 1 for 1 seconds
Fri Mar 13 09:57:22 2009 : Debug: Going to the next request
Fri Mar 13 09:57:22 2009 : Debug: Waking up in 0.9 seconds.
Fri Mar 13 09:57:23 2009 : Info: Sending delayed reject for request 1
Sending Access-Reject of id 142 to 10.20.30.40 port 32776

>From this code...

authorize {
        preprocess
        auth_log
        chap
        mschap
        files
        redundant {
                ldap
                group {
                        update control {
                                Response-Packet-Type = Do-Not-Respond
                        }
                        ok
                }
        }
}

As the group returns ok, the Response-Packet-Type is presumably being
executed fine, but still that reject is coming out of the bottom of all of
it... any clues? all other sections in the sites-enabled/default file are
default. Could something elsewhere be overriding it?

Thanks

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