<br><br><div class="gmail_quote">On Fri, Mar 13, 2009 at 8:13 AM, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com">aland@deployingradius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Chris Phillips wrote:<br>
> I've set up a 2.1.4 server, and working pretty well with authentication<br>
> against LDAP alone. What I've noticed though is that if the LDAP server<br>
> is down on the same box then the LDAP module, rightfully, fails. However<br>
> whilst this leaves the service unable to authenticate the user, it still<br>
> replies back with a REJECT packet to the client. As such the client<br>
> switch / router whatever, doesn't try the next server in it's config, as<br>
> it's had a valid RADIUS response.<br>
<br>
</div> Ah... if both ldap modules fail, then the redundant{} section returns<br>
fail, and the request stops being processed.<br>
<div class="im"><br>
> Is there any way to force a logic whereby if the ldap module fails, it<br>
> would drop the RADIUS request on the floor, to make it look like a<br>
> service failure to the client? Kinda wrecks our resiliency model if not!<br>
> We're only using a single ldap server per box, but even if we were using<br>
> other ldap servers on other servers, there still is a logic whereby it<br>
> may be impossible to reach any LDAP server whilst another FreeRADIUS box<br>
> can reach one, but is of a lower order of preference so can't be used.<br>
<br>
</div> Try:<br>
<br>
authorize {<br>
...<br>
redundant {<br>
redundant {<br>
ldap1<br>
ldap2<br>
}<br>
<br>
group {<br>
update control {<br>
Response-Packet-Type = Do-Not-Respond<br>
}<br>
<br>
ok<br>
}<br>
}<br>
}<br>
<br>
That should work better...<br>
<br>
The outer "redundant" block says:<br>
<br>
try the first "redundant" block.<br>
if it fails, try the "group" block<br>
<br>
The inner "redundant" block says:<br>
<br>
try ldap1<br>
if it fails, try ldap2<br>
if it fails, return fail<br>
<br>
The inner "group" block says:<br>
<br>
update the control list so that the server doesn't respond<br>
force an "OK" return code<br>
<br>
I don't have time to try this now... but if it works, we can put a<br>
sample in the default configuration.<br>
<font color="#888888"><br>
Alan DeKok.</font></blockquote><div><br>Thanks Alan, here's where I've ended up so far... <br></div><div><br>Fri Mar 13 09:57:22 2009 : Error: rlm_ldap: (re)connection attempt failed
<br>Fri Mar 13 09:57:22 2009 : Info: [ldap] search failed
<br>Fri Mar 13 09:57:22 2009 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0
<br>Fri Mar 13 09:57:22 2009 : Info: +++[ldap] returns fail
<br>Fri Mar 13 09:57:22 2009 : Info: +++- entering group {...}
<br>Fri Mar 13 09:57:22 2009 : Info: ++++[control] returns fail
<br>Fri Mar 13 09:57:22 2009 : Info: ++++[ok] returns ok
<br>Fri Mar 13 09:57:22 2009 : Info: +++- group returns ok
<br>Fri Mar 13 09:57:22 2009 : Info: ++- policy redundant returns ok
<br>Fri Mar 13 09:57:22 2009 : Info: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
<br>Fri Mar 13 09:57:22 2009 : Info: Failed to authenticate the user.
<br>Fri Mar 13 09:57:22 2009 : Auth: Login incorrect: [fbloggs] (from client my-switch port 0 cli 10.10.10.10)
<br>Fri Mar 13 09:57:22 2009 : Info: Using Post-Auth-Type Reject
<br>Fri Mar 13 09:57:22 2009 : Info: +- entering group REJECT {...}
<br>Fri Mar 13 09:57:22 2009 : Info: [attr_filter.access_reject] expand: %{User-Name} -> fbloggs
<br>Fri Mar 13 09:57:22 2009 : Debug: attr_filter: Matched entry DEFAULT at line 11
<br>Fri Mar 13 09:57:22 2009 : Info: ++[attr_filter.access_reject] returns updated
<br>Fri Mar 13 09:57:22 2009 : Info: Delaying reject of request 1 for 1 seconds
<br>Fri Mar 13 09:57:22 2009 : Debug: Going to the next request
<br>Fri Mar 13 09:57:22 2009 : Debug: Waking up in 0.9 seconds.
<br>Fri Mar 13 09:57:23 2009 : Info: Sending delayed reject for request 1
<br>Sending Access-Reject of id 142 to 10.20.30.40 port 32776
<br> <br>From this code...<br><br>authorize {
<br> preprocess
<br> auth_log
<br> chap
<br> mschap
<br> files
<br> redundant {
<br> ldap
<br> group {
<br> update control {
<br> Response-Packet-Type = Do-Not-Respond
<br> }
<br> ok
<br> }
<br> }
<br>}
<br> <br></div></div>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?<br>
<br>Thanks<br><br>Chris<br>