MBR Extend and Limit fields

Josh Hillman ( (no email) )
Tue, 21 Apr 1998 11:23:01 -0400

I always thought that if Extend was greater than Limit, the Extend value
would override the Limit value rather than add to it. In other words, if
an MBR for "Test" had the following settings:
Expiration date: 4/1/98
Extend = 0
Limit = 7
the person would no longer be able to log on after 4/8/98 12AM.

Change the Extend to 14
the person would no longer be able to log on after 4/15/98 12AM.
(overriding the Limit of 7).

I just noticed that these two values are added together such that in the
second example, the person can log in up through 4/22/98 12AM.

Am I just now noticing this for the first time and it's always been this
way, or did something get altered when I ran the "rad25_upd.sql" file that
came with RadiusNT 2.5 Beta?

I just realized that this also poses a bit of a problem with Serv-U
integration. Presently, if you FTP into the system using Serv-U, you will
not be able to log in if the Expiration date has already passed--regardless
of any number that might be present in the Limit field. If you put a
number in the Extend field, the FTP user will be able to get in <Extend>
days past the Expiration. The problem is that if the Extend value and the
Limit value are added together, the FTP user will be able to get in
<Extend> days past the Expiration, while the same user would be able to
dial-up (<Extend> + <Limit>) days past the expiration, obviously not
matching.

If the account is expired and the Extend and/or Limit value have also
passed, Emerald's RadLogs.Data will display:
If using RadiusNT 2.2.41:
The date that the user was no longer able to log on.
If using RadiusNT 2.5.81:
A negative integer that appears to, in some way, represent the
time that has passed since the date that the user was no longer
able to log in.

Emerald 2.1.11
SQL 6.5 SP3 on NT 4.0 SP3 (Intel)
RadiusNT 2.2.41, 2.5.81

Josh Hillman
hillman@talstar.com