John Hough wrote:
>
> Hello,
>
> Our main need for this revolves around the following attributes.
>
> For the Tigris
>
> ACC-Ip-Pool-Name="xxxxxxxx"
> ACC-DNS-Server-Pri=xxx.xxx.xxx.xxx
> ACC-DNS-Server-Sec=xxx.xxx.xxx.xxx
>
> For the Ascend
>
> Ascend-Assign-IP-Pool=xx
> Ascend-Client-Primary-DNS=xxx.xxx.xxx.xxx
> Ascend-Client-Secondary-DNS=xxx.xxx.xxx.xxx
>
> My original thought was to put both of them into the user profile and then
> strip out the other vendor's attribute from the reply. If it was going to
> the Tigris strip everything out starting with Ascend, and to the Ascend
> strip everything out starting with ACC. This way it would be portable, and
> if we mixed up our equipment even more it would be replicatable..
hi John, et. al.,
The Profiles stuff started out from a request from one of my clients.
For their project, we needed a way to specify sets of attributes for
user groups, and at the same time had a need to support several NAS
types.
The ultimate form of the new profile mechanism permits this, and does it
in a rather elegant way. Using the Identifier tags in clients, we were
able to clearly identify groups of NAS servers (both types, and
wholesale dialup vendors).
The profile tags on the user accounts permit differing actions for
different users. For example, a user who hasn't paid can be retagged
with a different profile (e.g. "notpaid") and filters can be added to
the attributes sent to the NAS so the user can ONLY access the ISP's
website to do something about their non-payment. There are lots of other
uses (my client has many user groups, each defined to get different
things).
For your simpler case, you should be able to define a pseudo-attribute
for Profile set equal to "dialup", then use the ProfileDefs stuff to
select among NAS types. While this wastes half the power of the feature,
it sets you up well for using the other part (storing profile names in
the user database) should you ever get to the point where you need that.
My client generously agreed to allow the custom changes made for them to
be made available to all. This was the largest, but not the only, piece
donated back to the Radiator effort after the project completed.
As a result of the project, we have two servers running Linux which
serve a user base of almost a million subscribers, with something like 4
million authentication transactions a day. The new servers replaced
servers running another, less-flexible Radius product.
> -----Original Message-----
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 01, 2000 12:17 AM
> To: John Hough
> Cc: Jeremy C. Reed; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) trying to use hooks getProfiles
>
> Hello John, 'lo Jeremy -
>
> On Thu, 01 Jun 2000, John Hough wrote:
> > Hugh,
> >
> > Back several months ago we had this same discussion and I passed our
> > emails on to Jeremy (He works for me). Our configuration has several
> > hundred realms on a centralized Radius server, we support local
> > authentication via flat file and proxying the radius request to remote
> > servers for some of our dealers. In this scenario would your
> > recommendation still apply or is it back to the <Client ...> tag as in the
> > emails that we had discussed this. Being able to support several
> > different NAS devices is appealing to us, especially if we can provide
> > support for their Vendor attributes as needed based on where the request
> > is coming from..
> >
>
> If you want to return different attributes to different types of NAS
> equipment,
> then using the Client Identifier tag is a good way of doing it. As mentioned
> previously, the example getProfile/replaceProfile hooks were developed for a
> specific purpose, and that was to translate a per-user symbolic Profile name
> to
> a per-NAS-specific set of attributes.
>
> In your scenario above, it is not clear to me how you intend to supply the
> per-user Profile name if you want to use the example hooks directly. And in
> any
> case, it may very well be that you will need to come up with a different
> approach and develop hooks of your own to address your own requirements.
>
> Perhaps you can clarify your requirements?
>
> thanks
>
> Hugh
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
> Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
>
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
-----------------------------------------------------------------
Daniel Senie [EMAIL PROTECTED]
Amaranth Networks Inc. http://www.amaranth.com
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
