This clause allows you permanently pre-define how to reply to a
request, depending only on the type of request. You can specify whether to
ACCEPT
, REJECT
, IGNORE
or CHALLENGE
each type of request. The default behaviour
is to IGNORE
all requests.
The following result codes are recognised. They are not case sensitive,
and may be embedded within a longer string:
- ACCEPT
- REJECT
- IGNORE
- CHALLENGE
This clause can be useful in a number of cases:
- As a fallback at the end of an AuthBy chain, so that if all your
authentication methods are failing due to internal problems, you can let
all users on, irrespective of password.
- As a step in a chain of AuthBy clauses to update requests or do
other processing between AuthBys.
- As a trap for certain types of requests, either in a distinct
handler, or at the beginning of a chain of AuthBy clauses.
Tip
The RADIUS protocol does not define an accounting reject
message. For accounting requests, REJECT and CHALLENGE are the same as
IGNORE.
This example clause will ACCEPT all Access Requests, ACCEPT
Accounting Starts and Stops, and REJECT everything else:
<AuthBy INTERNAL>
AuthResult ACCEPT
AcctStartResult ACCEPT
AcctStopResult ACCEPT
DefaultResult REJECT
</AuthBy>
<AuthBy INTERNAL>
also supports a number of
hooks. You can define a Perl hook to handle some or all requests. Requests
that are not handled by a hook will be handled according to the result
code defined for that type of request. See
goodies/internalhook.cfg
for sample hooks.
Hooks are passed information about the request and the hook is expected
to return a list of two values.The values are result code, one of:
$main::ACCEPT
$main::REJECT
$main::IGNORE
$main::CHALLENGE
$main::REJECT_IMMEDIATE
to indicate the result of the request, and textual reason message
providing information about the result. All hooks in <AuthBy
INTERNAL>
are passed the same arguments in this order:
- Reference to the current request, $p
- Reference to the partly formed reply packet for $p
- Reference to additional check items. This can safely be ignored in
most circumstances.
Tip
<AuthBy INTERNAL>
cannot be
used to authenticate any EAP-TLS, TTLS or PEAP protocols directly, but it
can be used in conjunction with AuthBy FILE to achieve the same
thing:
<AuthBy INTERNAL>
Identifier myinternal
.....
</AuthBy>
<Realm DEFAULT>
<AuthBy FILE>
Filename %D/users
EAPType TLS
.....
and in the users file:
DEFAULT Auth-Type=myinternal
This
has the effect of using <AuthBy FILE>
to do the
EAP authentication handling, certificates etc., and the
<AuthBy INTERNAL>
to just authenticate the user
name.