Hello Dmitry -
On Wed, 02 Feb 2000, Dmitry Niqiforoff wrote:
>
> > > 3) Something like "Fall-Through" in "<Handler> sections so packet can
> > > go through several handler sections.
> > >
> >
> > I'm not sure I understand what you mean, I'm afraid. Handlers are designed to
> > match on specific attributes in the Request packet and take the corresponding
> > action. What exactly do you have in mind, remembering that you can chain
> > multiple AuthBy's in the same Handler, and define a DEFAULT at the end to catch
> > everything you haven't specified explicitly?
>
> For now, Radiator process the first <Handler> section which matches the packet.
> Any following <Handler> which may match this packet too will never be processed. I
> think it would be very helpful if there will be something like "Fall-Through" in
> <Handler> section which will control whether the following <Handler> sections
> should be processed or they shouldn't (default behaviour).
>
> For example, I have different Realms which should be authenticated through
> different methods. Let's say, we have realm "test" which should authenticate by
> other Radius server. We have the following in radius.cfg:
>
> <Handler Realm=test>
> <AuthBy RADIUS>
> ...
> </AuthBy>
> </Handler>
>
> Then, we need to save accounting information on both local and remote server.
> What should we to do? We have to add another <Handler> section for non-empty
> "Acct-Status-Type" value pair. We add the following BEFORE the section shown
> above:
>
> <Handler Realm=test, Acct-Status-Type=/^Start|^Stop/>
> <AuthBy RADIUS>
> ..
> </AuthBy>
> <AuthBy SQL>
> [some clauses to save accounting info into local database]
> </AuthBy SQL>
> </Handler>
>
> Right?
>
> But AuthBy SQL is a little bit complicated to repeat it several times for each
> realm. So, why not use the following:
>
> #Section to handle "test" realm authentication and accounting
> <Handler Realm=test>
> <AuthBy RADIUS>
> ...
> </AuthBy>
> FallThrough=true
> </Handler>
>
> #General accounting section
> <Handler Acct-Status-Type=/^Start|^Stop/>
> <AuthBy SQL>
> ...
> AccountingStartsOnly
> </AuthBy>
> <AuthBy SQL>
> ...
> AccountingStopsOnly
> </AuthBy>
> </Handler>
>
> In the example above there is: 1-st <Handler> will process authentication and
> accounting requests and send them to remote RADIUS server, and the 2-nd <Handler>
> will also process accounting requests for ALL the rest, and also sends accounting
> to local database.
>
The usual way to do this is as follows:
# configure AuthBy RADIUS with Identifier ProxyRadius for later reference
<AuthBy RADIUS>
Identifier ProxyRadius
...
</AuthBy>
# configure AuthBy SQL for AccountingStartsOnly
# use Identifer SQLAccountingStarts for later reference
<AuthBy SQL>
Identifier SQLAccountingStarts
AccountingStartsOnly
...
</AuthBy>
# configure AuthBy SQL for AccountingStopsOnly
# use Identifer SQLAccountingStops for later reference
<AuthBy SQL>
Identifier SQLAccountingStops
AccountingStopsOnly
...
</AuthBy>
# configure AuthBy GROUP to link Accounting AuthBy's
# use Identifer SQLAccounting for later reference
<AuthBy GROUP>
Identifier SQLAccounting
AuthByPolicy ContinueAlways
AuthBy SQLAccountingStarts
AuthBy SQLAccountingStops
</AuthBy>
# configure Handlers to use clauses defined above
<Handler Acct-Status-Type=/^Start|^Stop/>
AuthBy SQLAccounting
</Handler>
<Handler Realm = test>
AuthBy ProxyRadius
</Handler>
Note that the above is just an example, but you should get the idea - define
your AuthBy clauses once with Identifers, then define AuthBy GROUP's to link
the ones that go together (also with Identifiers), then refer to the relevant
Identifers in your Handlers with AuthBy Identifier (note that the "<>" are not
required when Identifiers are used).
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
