Are you updating the LastModifyDate on the account? RadiusNT will
periodically (cache setting) check the DB for users that have changed
and update those entries. However, if you don't update LastModifyDate,
then the cache doesn't know to update the entry.
> I'd like to have new password changes propogated out within 15 minutes - at
> the moment I build the MasterAccounts/SubAccounts table every couple of
> hours from an export process on another database, so the LastModified date
> is updated regularly -- will this affect things?
I'm not sure this is optimial, but it should. This would tell RadiusNT
to
reload the entire cache every time you update those tables.
> It seems that when the RadiusNT software goes to check a user in the
> database, rather than from its cache, it does this.. (log extract)
>
> radrecv: Request from host ca8be332 (Test) code=1, id=242, length=86
> NAS-Identifier = 202.139.2xx.xx
> NAS-Port = 122
> NAS-Port-Type = 5
> User-Name = "abc"
> Caller-Id = "202.139.23x.xx"
> Password = "b=\351'h7\033\351\203Q\346\337\202\331\245\374"
>
> SQL Statement: {CALL RadGetUser('abc',NULL)}
>
> Sending Reject of id 242 to ca8be332 (UUNET) Jun 01 16:31:19 2000 [NOTICE]:
> User: abc Bad Password user:test database:test2
> Resp Time: 10 Auth: 2/3 -> 5 Acct: 0/0/0 -> 1
>
> So in the above info, the database password for user "abc" is really "test",
> but RadiusNT still thinks it is "test2".
No. Test is what the user typed in (the authentication request).
Database is
what RadiusNT pulled from the DB.
> However - it has done a query:
>
> SQL Statement: {CALL RadGetUser('abc',NULL)}
>
> But why does it send NULL for the password (that stored procedure will
> naturally return 0 rows)??
An earlier version of the RadGetUser proc was incorrect as you note
above.
NULL for the password should return all users with that name. The
corrected
proc is in the current distribution.
> At the moment, I'm setting the "init load" setting high, and restarting the
> server every X minutes (via 'net stop radiusnt'; 'net start radiusnt') in
> the task scheduler - a hack which works (reload forces the entries to be
> re-cached), but a dirty, dirty hack.
Check out Chapter 9 in the Radius 3 docs. It lists a set of special
users that you can use with radlogin to trigger events. One that might
be useful in your situation is *LastModifiedAccounts*, which can be used
to tell RadiusNT to immediately check the LastModifyDate fields and
reload any changes. You could calls that after a DB update to do an
immediaite update to the cache.
--Dale E. Reed Jr. Emerald and RadiusNT/X__________________________________________IEA Software, Inc. www.iea-software.com
For more information about this list (including removal) go to:http://www.iea-software.com/support/maillists/liststart