I see that at the top of the documentation page (much forehead slapping),
but you might want to add the specific version info on the support.html
page where you describe the links so the difference is more obvious.
>
> > 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.
All of our ISDN accounts are authenticated routed subnets over an Ascend MAX
so a defaults table is where I would puts lots of stuff like
"Ascend-Require-Auth=Require-Auth", etc., or for dial-outs and routes,
"Password=ascend", etc.
Also, for dialups, it would be nice to add a fixed IP to a particular user
without having to remember to go back and add things like User-Service and
Idle-Timeout and Session-Timeout.
Changes in policy would not have to be applied individually to all the
special cases and scripting is easier if adding an attribute doesn't require
checking to see if the RadATConfigs duplication was already done.
>
> > 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. :(
As is the default now, if a user wants to stupidly have three versions of
the same attribute with different values, nothing is stopping him.
Similarly, you could (by default) just let the user make the mistake and
figure out what's wrong. You could then add the explicit alternatives to
that of 1: Custom attributes override defaults; and 2) Defaults always
prevail.
Actually a default of "custom overrides" would allow those who already
duplicate default RadATConfigs to turn on a "RadATConfigs applies to all"
option without breaking anything, and might be a little more forgiving to
the bonehead user who doesn't get it. And come to think of it, would allow
exceptions to policies to be easier to implement (e.g., for user
"bigdownload", Session-Timeout=8 instead of 6, but everything else the
same).
>
> 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
>
-Robert F. O'Connor
System Administrator, Metro.Net
sysadmin@metro.net