Old password 'grace period'

[A.L.M.Buxey at lboro.ac.uk]

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