On Fri, Mar 13, 2009 at 8:13 AM, Alan DeKok <aland@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