RE: User Restrictions

Tim Ballingall ( tim@mazda.com.au )
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
feature.

Thanks for the help & clarification Dale..

-----Original Message-----
From: Robert F. O'Connor [mailto:sysadmin@metro.net]
Sent: Thursday, August 27, 1998 9:11 AM
To: radiusnt@iea-software.com
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
10
don't very explicitly get that point across. In addition, the inclusion
of
the "User-Service" and "Framed-Protocol" entries under the ISDN
profile-type
in RadATConfigs would seem to suggest the cumulative assumption, since
ISDN
profiles wouldn't generally be very useful without user-specific
attributes.

Regardless, I would suggest that a future version of RADIUS include the
option of RadATConfigs and RadConfigs being either exclusive (the
default)
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
least,
it is the extremely rare exception that would need to override those
"default" settings, even when most or all profiles have custom
attributes.

-Robert F. O'Connor
System Administrator, Metro.Net
sysadmin@metro.net

-----Original Message-----
From: radiusnt-request@iea-software.com
[mailto:radiusnt-request@iea-software.com]On Behalf Of Dale E. Reed Jr.
Sent: Wednesday, August 26, 1998 2:52 PM
To: radiusnt@iea-software.com
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
user's
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
the
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
is
where you would put the attributes for generic account types. You would
not
put user specific attributes in the RadATConfigs table.
>
> If RadiusNT finds entries in the RadConfigs table that matches the
user's
AccountID, it does not look into the RadATConfigs table for Account
Type
matching entries. Therefore, if you do add an entry in the RadConfigs
table, you must add the complete set of attributes, since RadiusNT will
not
bring other attributes in.
>

> Tim Ballingall wrote
> >
> > You seem to be using it the same as I am, except that when I have
some
> > values entered in RadConfig they are causing the generic info ( All
info
> > ) 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.  (daler@iea-software.com)_________________________________________________________________       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |   http://www.iea-software.com

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.