On 03.05.19 18:35, Alan DeKok wrote:
On May 3, 2019, at 10:40 AM, Wladyslaw Jankowski <wladekj@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