Hello Bret, Hello Herman -
As Bret says, Realms are a subset of Handlers, but they are also much more efficient. A Realm is selected by doing a table lookup on the specified string, whereas the list of Handlers is evaluated in the order that they appear in the configuration file. In both cases the first match is the only match.
In general, a simple configuration based on Realms is very easy to understand and very efficient.
It is certainly true that Handlers are far more flexible, but you probably don't want hundreds of Handlers in your configuration file.
In Herman's case, I generally suggest using Identifiers in the Client clauses and Handlers to suit:
# define Client clauses
<Client 1.1.1.1>
Identifier SomeTag
....
</Client><Client 2.2.2.2>
Identifier SomeTag
....
</Client><Client 3.3.3.3>
Identifier AnotherTag
....
</Client>......
# define Handlers
<Handler Client-Identifier = SomeTag>
.....
</Handler><Handler Client-Identifier = AnotherTag>
.....
</Handler>.....
On Tuesday, Jul 1, 2003, at 04:14 Australia/Melbourne, Bret Jordan wrote:
Use handlers, never use realms.. Handlers can do everything that realms can do and more.
Bret
Herman verschooten wrote:
Hi,
I am now using Radiator with a single default-realm for 4 different Client-sets. I use a rewrite username to strip off the realm if a client provides it. I now want to split the authentication to be able to use 2 separate Online-algorithms. What do you propose I use, A Handler or 2 different realms with a default-realm in the client-clause? Or can a handler trigger on the client used?
TX,
Herman
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bret Jordan Dean's Office Computer Administrator College of Engineering 801.585.3765 University of Utah [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=== 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.
NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening?
-- 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.
