Fwd: Re: SQL query as fallback to auth script?

[Wladyslaw Jankowski]

On 03.05.19 18:35, Alan DeKok wrote:

>> On May 3, 2019, at 10:40 AM, Wladyslaw Jankowski <wladekj at interia.pl> 
>> wrote:
>>
>> Learn how to format your messages. When you make it difficult for us 
>> to help you, we're inclined to avoid helping you.
Please accept my apologies for my last message's formatting. What was 
written in plain ASCII became somehow re-formatted to HTML, and a lot of 
newlines were scrambled. Using different client now.

>> This is the idea: script should always reject - doing its thing 
>> behind the scenes - and allow for SQL fallback.
>>
>> That makes no sense whatsoever. If the script always rejects, then 
>> you always need a work-around for that reject.
>>
>> Why not just have the script do it's thing, and have it return an 
>> "ok" code?
The idea is for the script to ping the auth server (proprietary 
solution) for given user's NT hash, and store it in a local database for 
a short period of time. Script should always "Reject" and there is where 
I was hoping for an ability for an SQL fallback. This way the script 
would temporarily insert NT hash into the local database, and FreeRADIUS 
would query the database entry moments later. This would introduce a 
short delay but should work - would the fallback be possible.
> I can't "Accept" RADIUS auth with this script as it can't calculate 
> MSCHAP challanges and no cleartext password will be provided to it 
> (can't use PAP).
> Yes, FreeRADIUS does authentication. Your script doesn't. That's the 
> way it should work./
 From my understanding of MSCHAP RFC documents - access to the NT hash 
is required to calculate/validate the challenge and/or Authenticator 
field. The idea was for the RADIUS server not to have full access to the 
whole database but to fire up a script that would grab one given hash, 
store it in a local database, and allow FreeRADIUS to use "sql" 
authorization method to validate the MSCHAP challenge based on the NT hash.
> Perhaps you could set a password?
>
> Or, set "Auth-Type := Accept" if you want the user to always be accepted.
I can't blindly accept any given password without validation. The least 
insecure way I've figured out was to be able to grab one given hash and 
work with that. That's why the script was supposed to always "Reject" 
(or is there like a half-way-Reject allowing for fallback?).
> The problem here is that you're asking how to fix the "solution" you 
> came up with. That's bad practice. Instead, you should be describing 
> your requirements. We can then offer you advice as to how to meet 
> those requirements.

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

> So what are you trying to do? What *problem* are you trying to solve? 
> And don't answer "run the script and SQL". That isn't relevant. What 
> are the users trying to do? What answers do you want the RADIUS server 
> to return? And why?

Initial problem: with fancy-artsy authorization methods - the password 
is not being sent in clear text like it was with PAP - so there is no 
way to pass username and password to the script. Desired behavior: 
RADIUS server should Accept or Reject the request based on given 
credentials. I was hoping here to do this in such way that FreeRADIUS 
wouldn't have to have access to the full database but I guess that I'll 
have to go this path if it's the only viable option(?)


Thanks

WJ