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