Hi, > [JK] Tried that earlier Alan. Seems whenever is set ok = return, we > process no further. Here's the logs from a 'radtest', where testRadOld > is entered as the password (testRad is the new password, testRadOld is > the old password in the DB). We see the first query, where there is a > password mismatch, but the second query never happens (it does in other > configuration settings, but I never see it compare BOTH passwords to > what was received):
ooh. me sir, me sir! (said whilst jumping around holding hand in the air. the SQL module is not doing the checking - its simply collecting the Cleartext-Password for that User-Name (and thus, if user exists its returning 'ok' - therefore the group returns ok > [sql_new] User found in radcheck table > rlm_sql (sql_new): Released sql socket id: 3 > +++[sql_new] returns ok > ++- group returns ok now, the PAP module kicks in - and that compares the value sent versus the value got from SQL....and so heres where it breaks. > [pap] login attempt with password "testRadOld" > [pap] Using clear text password "testRad" > [pap] Passwords don't match > ++[pap] returns reject ta da! so, what you've actually got to do is run the pap method twice. once for the user-name/password from sql_new and once for the user-name/password from sql_old. one of those methods would work for a valid user.... thats a funky bit of group/failover requirement that'll have to be cooked up...maybe group { sql_new { pap ok = return } sql_old { pap ok = return } } or something along those broken lines ;-) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html