SQL query as fallback to auth script?

[Wladyslaw Jankowski]

Hi,

On 04.05.19 16:52, Alan DeKok wrote:
>> My requirements were basically that I would like to be able to authorize users with EAP-MSCHAPv2 / EAP-TTLS without having direct access to the db with NT passwords.
>    Well, it has to access the DB *somehow* in order to read the passwords.
>
>    From a practical point of view, there's no difference between FreeRADIUS accessing the DB directly, or using a script to do that.  The script is just security theatre.  It doesn't add any security.  It doesn't prevent any attacks.

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.


>> With PAP it is possible to pass %{User-Password} to the script but no such field is present in MSCHAPv2 packets. The fallback-idea was to blindly grab the (one given) hash from the proprietary solution and allow FreeRADIUS to validate credentials based on it. Short after it was supposed to be deleted from local store.
>    Why cache it if you're quickly deleting it?  That doesn't make any sense.
It wasn't supposed to be caching system... at least not caching these
password for longer than like 10 seconds to allow for fallback.
>    Having FreeRADIUS access the DB is the easiest approach.

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.


>    What you want do do is this:
>
> authorize {
> 	...
> 	sql
> 	if (notfound) {
> 		update control {
> 			NT-Password := `/path/to/script`
> 		}
> 	}
> 	...
>
>    The script can then:
>
> a) access the external DB to get the password
> b) insert the password into SQL
> c) return the hex password (0xabcdef...) as a string to stdout.

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). 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. 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!

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

(0)     [eap] = ok
(0)     update control {
(0)       Executing: /bin/python /scripts/radiusauth.py '%{User-Name}' 'failme':
(0)       EXPAND %{User-Name}
(0)          --> provided-username
(0)       Program returned code (0) and output '0x9853107D57DAC0881DE7676395A03F5F'
(0)       NT-Password := 9853107d57dac0881de7676395a03f5f
(0)     } # update control = noop
(0)   } # authorize = ok
(0) Found Auth-Type = eap
(0) # Executing group from file /etc/raddb/sites-enabled/default
(0)   authenticate {
(0) eap: Peer sent packet with method EAP Identity (1)
(0) eap: Calling submodule eap_tls to process data
(0) eap_tls: Initiating new EAP-TLS session
(0) eap_tls: Setting verify mode to require certificate from client
(0) eap_tls: [eaptls start] = request
(0) eap: Sending EAP Request (code 1) ID 1 length 6
(0) eap: EAP session adding &reply:State = 0x2cec41732ced4cc5
(0)     [eap] = handled
(0)   } # authenticate = handled
(0) Using Post-Auth-Type Challenge
(0) # Executing group from file /etc/raddb/sites-enabled/default
(0)   C	hallenge { ... } # empty sub-section is ignored
(0) Sent Access-Challenge Id 221 from 127.0.0.1:1812 to 127.0.0.1:28318 length 0
(0)   EAP-Message = 0x010100060d20
(0)   Message-Authenticator = 0x00000000000000000000000000000000
(0)   State = 0x2cec41732ced4cc52ba998708fe9bf68
(0) Finished request

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

>    But realize that this *also* means that the script (and thus FreeRADIUS) has write permission to the SQL authentication table.  That's a security problem.  The default config has the authentication tables read-only for very good reason.

Understood.


Thank you,
WJ