Re: User Restrictions

Dale E. Reed Jr. ( (no email) )
Thu, 27 Aug 1998 17:22:10 -0700

Robert F. O'Connor wrote:
>
> 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

The HTML documentation on the website is for RadiusNT 2.2. The RadiusNT
2.5 documentation is available from our FPT site in Word97 format. We
are working to put it into HTML format.

> 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.

A lot of the ISDN equimpment looks just like a normal user. Most newer
gear does NAT, can take a dynamic IP Address, etc. Routing a subnet
(whether over ISDN or dialup) is completely different. The defaults are
just that, defaults. They are not meant to be a complete solution to
all
possibilities.

> 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.

This is something that we have looked as for a while. Unfortunately,
its NOT a trivial thing to do. What happends if you have conflicting
attributes. For example, Framed-Address would almost always conflict,
since the RadATConfigs should have a 255.255.255.254 setting to tell
the NAS to assign an address. On a per-attribute basis, the answer
could be, include the RadConfigs entry or include both. We choose
the current implementation because there is NO grey area of confusion
on how to interupt which attributes the user gets. Adding the ability
to join the two based on some sore of rules complicates this and add
support nightmares for us, because people simply have to play with an
option that is available, whether they understand it or not. :(

I'm very open and willing to listen to suggestions, but I want the
whole picture to be in the clear when discussing adding options.

-- 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