(RADIATOR) passing information between Radiators and authby question

[Hugh Irvine]

Hello Viraj -

We have recently created the "OSC-AVPAIR" vendor specific attribute in the  
Radiator dictionary for exactly this purpose:

VENDORATTR      9048 OSC-AVPAIR                 0 string

The attribute can be used like this:

	AddToRequest OSC-AVPAIR = ".........."

You can put anything you like in the string "..........".

As you mention, the Class attribute is the only way to have a NAS add 
something to the accounting requests sent for a particular session.

Finally, your configuration file and users file should probably look 
something like this:

# define Client clauses

<Client 1.1.1.1>
	Identifier SomethingUseful
	......
</Client>

<Client 2.2.2.2>
	Identifier SomethingUseful
	......
</Client>

<Client 3.3.3.3>
	Identifier SomethingElse
	......
</Client>

<Client 4.4.4.4>
	Identifier SomeOtherThing
	......
</Client>

# define AuthBy clauses

<AuthBy .....>
	Identifier DoA
	.....
</AuthBy>

<AuthBy .....>
	Identifier DoB
	.....
</AuthBy>

<AuthBy GROUP>
	Identifier CheckUsers
	RewriteUsername .....
	AuthByPolicy ContinueUntilAccept
	AuthBy DoA
	AuthBy DoB
	......
</AuthBy>

.....

# define Handlers

<Handler Client-Identifier = SomethingUseful>
	AuthBy CheckUsers
	.....
</Handler>

......

Now the above does not correspond directly to what you describe below, but 
you should get the idea (if not please ask more questions).

regards

Hugh


On Tue, 14 May 2002 22:01, Viraj Alankar wrote:
> Hello,
>
> I am trying to determine what's the best way to pass information between 2
> Radiator's, one proxying requests to the other. For example, say I have
> Radiator A proxying requests to Radiator B. I would like to pass some
> request specific information from A to B, such as a VISP ID. I thought of
> using Class, but there could be requests coming to A that are already using
> Class, so there may be some conflict.
>
> So I'm wondering what's the best way to deal with this. Create a new
> attribute in each dictionary and use that? If so, how can I use something
> that I'm sure will not conflict with other vendors? Also, I need the
> attribute to come in accounting packets as well. I only know of Class that
> is honored by RASes as being returned in accounting.
>
> Another question I have is using Auth-By in a users file. For example:
>
> <Handler NAS-IP-Address = 1.2.3.4>
>         <AuthBy FILE>
>                 Filename nas-1.2.3.4
>         </AuthBy
> </Handler>
>
> nas-1.2.3.4:
>
> DEFAULT Calling-Station-Id = 111, Auth-Type = DoA
>
> DEFAULT Calling-Station-Id = 222, Auth-Type = DoB
>
> First, is this method efficient if we have up to 500 RASes?
>
> Suppose I want to do a RewriteUsername to ALL the authbys (DoA and DoB), is
> there a way I can do something like:
>
>
> DEFAULT Auth-Type = DoRewrites
>
> DEFAULT Calling-Station-Id = 111, Auth-Type = DoA
>
> DEFAULT Calling-Station-Id = 222, Auth-Type = DoB
>
> where it will fall through after the first one? I was thinking of making an
> AuthBy DoRewrites that returns IGNORE. In that case it should fall through
> correct?
>
> Basically I would like to do the rewrites in the users file level and not
> in the Handler level.
>
> Thanks,
>
> Viraj.
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.