SQL query as fallback to auth script?

[Alan DeKok]

On May 6, 2019, at 11:16 AM, Wladyslaw Jankowski <wladekj at interia.pl> wrote:
> Devices that would have access to the RADIUS server are located in
> various locations and for security reasons it was safer to allow access
> via client-side script - so server-side script can be monitored for
> anomalies like brute-force attempts. But it can be done other way, too.

  I'm saying that it's not safer.

> It wasn't supposed to be caching system... at least not caching these
> password for longer than like 10 seconds to allow for fallback.

  If you're not caching it, then there's no need for SQL.  And "allowing for fallback" isn't necessary.  Just have the script return the correct password

> I understand but was hoping to avoid it as it would require additional
> layer of security (IPsec tunnel or something similar, from each client
> to the RADIUS server) for RADIUS packets to travel over the internet.

  That's what people often do.

  But... how does a shell script on the RADIUS server side change the security of packets going over the internet?

  Answer: it doesn't.

> OK. From my understanding - 1st login attempt would always fail but
> following ones would use the "cached" password (so I can't delete it
> after 10 seconds).

  No.  That's not what it does.

  It look up the cached password in SQL *first*, and only if it's not found, does it run the script.

> Probably better to go with "FreeRADIUS with direct
> SQL access" approach then, than to slowly create a copy of the database.
> 
> But what is the reason for c)? I can see that printing the hash (lower
> or upper case) doesn't seem to have an effect.

  If you follow my advice, it *will* have affect.  If there's no NT-Password in SQL, then the server can get one from the script.

> Would that work (if
> FreeRADIUS could use the hash printed to stdout) - this might be a
> solution not requiring local databases and no second login attempts!

  It doesn't need multiple login attempts.  And yes, you can just run a script and have the output assigned to an attribute.  See "man unlang".  This is documented.

  You can just get rid of SQL, and do:

	update control {
		NT-Password := `/path/to/script ... arguments ...`
	}

  But again, the shell script doesn't add any security.  It's a waste of your time.

> What I'm getting now, using the password 'dupa.8' seems like
> Access-Challenge is being treated as Access-Reject by the VPN software.

  Ask the vendor of the VPN software how their product works.

> Authorize "ok", authenticate "handled" - what might be the reason for another
> Access-Challenge, than?

  EAP uses multiple challenges.  That's how it works.

  Alan DeKok.