Hello Dan -
The best way to do this sort of thing is like this:
# define Client clauses
<Client 1.1.1.1>
Identifier Ascend-Type-A
.....
</Client>
<Client 2.2.2.2>
Identifier Ascend-Type-A
.....
</Client>
<Client 3.3.3.3>
Identifier Ascend-Type-B
.....
</Client>
<Client 4.4.4.4>
Identifier Ascend-Type-C
.....
</Client>
.......
# define AuthBy clauses
<AuthBy ...>
Identifier Auth-Ascend-Type-A
.....
</AuthBy>
<AuthBy ...>
Identifier Auth-Ascend-Type-B
.....
</AuthBy>
<AuthBy ...>
Identifier Auth-Ascend-Type-C
.....
</AuthBy>
......
# define Handlers
<Handler Client-Identifier = Ascend-Type-A>
AuthBy Auth-Ascend-Type-A
......
</Handler>
<Handler Client-Identifier = Ascend-Type-B>
AuthBy Auth-Ascend-Type-B
......
</Handler>
<Handler Client-Identifier = Ascend-Type-C>
AuthBy Auth-Ascend-Type-C
......
</Handler>
......
Hope that helps.
regards
Hugh
On Wednesday, Feb 5, 2003, at 10:08 Australia/Melbourne, Dan Melomedman wrote:
We are getting into compatibility problems with different Ascend NASes from our providers, which requires us to run different AuthBy for each. Since we use them with the same realms, what is the best way to differentiate NASes? Rewrite realms to something weird like realm.com-provider in the <Client>s? Any other way? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
