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.