Dropping requests when no authentication possible

[Alan DeKok]

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.