Authentication Source Order

[Alan DeKok]

On Oct 26, 2021, at 4:04 AM, clay at milos.co.za wrote:
> I am trying to do something that seems a bit odd as I can't find it in any searches. Perhaps someone else here has done this before.

  Sometimes yes, sometimes no.  The "wonderful" thing about RADIUS is that people do so many things with it.  This makes it difficult to write documentation, and to find good worked examples.

> I have FreeRadius successfully connected and working, serving authentication requests from a Mysql DB. It's running on a pfSense firewall and configured via the GUI but I doubt that makes any difference.

  Nope.

> I'm authenticating users connecting via a secure network to reach services and would like to change the authentication logic. If the MySQL server is down (yes I know it shouldn't be or I should have redundant servers) I would like the Radius server to always return an Access-Accept.

  That's easy enough to do.

> I know this seems counter-intuitive for an authentication service but as I said it's via a secure network allowing users supplementary services that are better to give for free for a limited time than not to give at all in case of a backend outage.
> My thoughts on doing this were trying to authenticate via SQL first and then falling back to "users" file authentication with a RegExp or DEFAULT user to match a user pattern all users. Is this a good way to do it?

  If it's what you want, sure.

> From what I've seen, FreeRadius tries to use the users file before trying SQL by default but I changed the sites-enabled/default ordering and that seems to work for (notfound || noop) but not for ( fail ). If I use SQL and then (notfound || noop) then "file" and the user exists in the "users" file it works. DEFAULT user works as well for any user.
> Where I'm going wrong, I think is that in the sites-enabled/default it accepts the "fail" as a module response code but doesn't act on it when the sql1 fails. I've attached the debug log.
>        redundant sql {
>                sql1
>        }

  I don't know what that that means, or why you'd do it.  The "redundant" block is about failing over between *multiple* modules.  Having a "redundant" block with only one module doesn't make sense.

  There's also no need to name the "redundant" block.

>        if ( fail ) {
>                        files

  The "redundant" block fails over to the second module if the first one returns "fail".  So there's no need to check for "if fail, do files".  Just list "files" in the "redundant" block/

>                        if (notfound || noop) {
>                                reject
>                        }
>                }
>        }

  The default is to reject users who are unknown, and who don't have a password.  So these checks are not necessary.

  Just do:

	redundant {
		sql
		files
	}

  Then if "sql" is down, the "files" module will be used.  And if the user isn't found in either one, they will be rejected.

  Alan DeKok.