RE: User Restrictions

Tim Ballingall ( )
Thu, 27 Aug 1998 09:19:02 +1000

I would have to agree with this request. At the moment I'll have to key
all the details for my accounts into the RadConfigs table. That's not a
problem - I can write a form to do this, but it would still be a nice

Thanks for the help & clarification Dale..

-----Original Message-----
From: Robert F. O'Connor []
Sent: Thursday, August 27, 1998 9:11 AM
Subject: RE: User Restrictions

Is the HTML (online) version of the documentation different from the
downloadable one? The "Authentication Process" list is there, but the
additional paragraphs are not. I had not previously downloaded the Word
document, since the HTML was more convenient. By themselves, items 9 and
don't very explicitly get that point across. In addition, the inclusion
the "User-Service" and "Framed-Protocol" entries under the ISDN
in RadATConfigs would seem to suggest the cumulative assumption, since
profiles wouldn't generally be very useful without user-specific

Regardless, I would suggest that a future version of RADIUS include the
option of RadATConfigs and RadConfigs being either exclusive (the
or cumulative. The cumulative option would save a lot of work and, I
suppose, space and, if profile types are defined carefully and the
attributes in RadAtConfigs are wisely chosen, in my user profiles at
it is the extremely rare exception that would need to override those
"default" settings, even when most or all profiles have custom

-Robert F. O'Connor
System Administrator, Metro.Net

-----Original Message-----
[]On Behalf Of Dale E. Reed Jr.
Sent: Wednesday, August 26, 1998 2:52 PM
Subject: Re: User Restrictions

Robert F. O'Connor wrote:
> Is this in the docs anywhere?

See the Authentication process section in the ODBC Schema
chapter. Not only does it step-by-step outline this, but there
is a couple of paragrahs right below that specifically state
what I summarized below. For those who haen't looked, I'll quote
the docs below. :)

> Authentication Process
> When RadiusNT receives an incoming authentication request, the
> following steps are performed to authenticate the user:
> 1. Check to see if a record exists in the SubAccounts table (and
> related record in MasterAccounts via CustomerID field) with either
> a login or shell field matching the username attribute in the
> request. The active flag in both the SubAccounts and MasterAccounts
> table must not be 0.
> 2. If no match is found, send a reject.
> 3. If the requested password does not match the database
> password (with proper case check), send a reject.
> 4. If the saExpireDate Field is not NULL and the SubAccount
> saExpireDate plus Extension is before today, then send a reject.
> (This is only applicable to SQL Server or Sybase, as this is not
> supported by MS Access or Oracle.)
> 5. If the saExpireDate is NULL and the MasterAccounts
> maExpireDate plus extension and overdue is before today, then
> send a reject.
> 6. If Time banking is enabled and the Account's TimeLeft field
> is not NULL and less than 1, send a reject.
> 7. If concurrency checking is enabled, and the user is listed
> in the callsonline view (with more entries than they are allowed),
> send a reject.
> 8. If Server Access checking is enabled, and the user's Account
> Type does not have an entry in the ServerAccess table for the port
> they are logging into, send a reject.
> 9. If there are matching records in the RadConfigs table for the
> user's AccountID, send an ACK with them for the reply attributes.
> 10. If there are matching records in the RadATConfigs table for the
> user's Account Type, send an ACK with them for the reply attributes.
> 11. Send a reject.
> There are typically two ways to return a set of attributes for a
authentication. If you want to return a set of attributes specific to a
single user, then you should add records to the RadConfigs table which
correspond to the user's AccountID from the SubAccounts table. One of
primary uses of the RadConfigs table is to assign a specific IP address
to a
user, a unique set of routing information, or for user check attributes,
like Caller-ID.
> The RadATConfigs table has attribute sets for each Account Type. This
where you would put the attributes for generic account types. You would
put user specific attributes in the RadATConfigs table.
> If RadiusNT finds entries in the RadConfigs table that matches the
AccountID, it does not look into the RadATConfigs table for Account
matching entries. Therefore, if you do add an entry in the RadConfigs
table, you must add the complete set of attributes, since RadiusNT will
bring other attributes in.

> Tim Ballingall wrote
> >
> > You seem to be using it the same as I am, except that when I have
> > values entered in RadConfig they are causing the generic info ( All
> > ) in RadATConfig to be ignored..
> RadiusNT does not combine the results of the RadATConfigs with the
> RadConfigs table. If any records are found in the RadConfigs table,
> those are sent and the RadATConfigs table is not checked.

--Dale E. Reed Jr.  (       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |

This message has successfully passed virus checking.Mazda Australia takes every precaution to ensure email messages are virus free. For complete protection, you should virus test this message.