Many thanks for the information. The thing that really helped me was the
info about the last line in RadGetUser. Ours didn't have that line. I made
the change you described, and now it successfully authenticates those failed
accounts. This will help us keep customers from getting irate while I
continue to investigate the caching problems.
Thank you,
Greg White
Internet Network Administrator
Beaver Creek Cooperative Telephone Company
>-----Original Message-----
>From: Peter Deacon [mailto:peterd@iea-software.com]
>Sent: Thursday, February 10, 2000 6:10 PM
>To: 'radiusnt@iea-software.com'
>Subject: Re: [RadiusNT] Caching headaches
>
>
>On Thu, 10 Feb 2000, Greg White wrote:
>
>> Hello,
>> We are currently running Radius 3.0.147 on an NT4 SP4
>server, and running
>> into some problems with caching. The problems are as follows:
>
>> 1. It doesn't seem to be reliably picking up new users or modified
>> accounts.
>
>> I have gone so far as to modify the RadGetUserCache stored
>proc so that it
>> grabs the modified accounts for the entire previous day.
>The thought here
>> was that perhaps during times of heavy load, something was
>keeping Radius
>> from calling the procedure. We still have occasional times
>when it doesn't
>> get the new or modified users.
>
>It fetches updated users based on the accounts LastModifyDate. If this
>one isn't getting updated in your software when an account changes
>Radius won't re-cache unless the authentication fails or several days
>go by :(
>
>If your running a RadiusNT database (NOT Emerald!) You can run the
>queries below to install a trigger to have the database
>automatically keep
>LastModifyDate up to date.
>
>CREATE TRIGGER MA_Update ON MasterAccounts
>FOR UPDATE
>AS
>UPDATE ma SET LastModifyDate = getdate()
>FROM MasterAccounts ma, Inserted i
> WHERE ma.CustomerID = i.CustomerID
>GO
>
>CREATE TRIGGER SA_Update ON SubAccounts
>FOR UPDATE
>AS
>Update sa
>Set LastModifyDate = GetDate()
>From SubAccounts sa, Inserted i
>Where sa.AccountID = i.AccountID
>GO
>
>CREATE TRIGGER SA_Update2 ON RadConfigs
>FOR INSERT, UPDATE
>AS
>Update sa
>Set LastModifyDate = GetDate()
>From SubAccounts sa, Inserted i
>Where sa.AccountID = i.AccountID
>GO
>
>> 2. If a login attempt fails, the stored proc that RadiusNT calls is
>> RadGetUser "username", NULL. Should this be sending the
>password? It seems
>> like it is trying to double check the failed user, but of
>course with a NULL
>> password, they all fail.
>
>The last line of RadGetUser should read:
>
> AND (@password IS NULL OR sa.Password = @password)
>
>Radius will almost always retreive a list of all users with
>the same name
>and compare passwords internally... That's why the password
>parameter of
>RadGetUser is null.
>
>> Has anyone else encountered any caching problems like this?
>
>ciao,
>Peter
>
>
>For more information about this list (including removal) go to:
>http://www.iea-software.com/support/maillists/liststart
>
For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart