operation.texi

gnu 的radius服务器很好用的

in detail below.

@item Left-Hand Side (@LHS{})
The list of attribute-value pairs used for matching the profile
against an incoming request.

@item Right-Hand Side (@RHS{})
The list of attribute-value pairs that define the action to be taken
if the request matches @LHS{}.
@end table

The following GNU Radius configuration files keep data in a
matching rule format: @file{hints}, @file{huntgroups}, and
@file{users}. Although they keep data in a similar format, the rules
that are used to match incoming requests against the contents of these
files differ from file to file. The following section describes these
rules in detail.

@comment *L2****************************************************************
@node Request processing
@section Processing Requests
@cindex Processing requests

Upon receiving a request, @radiusd{} applies to it a number of checks
to determine whether the request comes from an authorized source. If
these checks succeed, the request is processed and
answered. Otherwise, the request is dropped and corresponding error
message is issued (@pxref{Logging}).

The following checks are performed:

@table @asis
@item Check if the username is supplied.
If the packet lacks the @attr{User-Name} attribute, it is not processed.
@item Check if the @NAS{} is allowed to speak.
The source IP of the machine that sent the packet is looked up in
the @file{clients} file (@pxref{clients file}). If no match is found,
the request is rejected.
@item Compute the encryption key.
Using the data from the packet and the shared key value from the
@file{clients} file, Radius computes the MD5 encryption key that will
be used to decrypt the value of the @attr{User-Password} attribute.
@item Process user-name hints.
@dfn{User-name hints} are special rules that modify the request
depending on the user's name and her credentials. These rules allow an
administrator to divide users into distinct groups, each group having
its own authentication and/or accounting methods. The user-name hints
are stored in @file{raddb/hints} (@pxref{hints file}).
@item Process huntgroup rules.
@dfn{Huntgroup rules} allow an administrator to segregate incoming
requests depending on the @NAS{} and/or port number they came
from. These rules are stored in @file{raddb/huntgroups}
(@pxref{huntgroups file}).
@item Determine whether the request must be proxied to another @RADIUS{} server.
The requests pertaining to another realm are immediately
forwarded to the remote @RADIUS{} server for further
processing. @xref{Proxying}, for the description of this process.
@item Process individual user profiles
This step applies only to authentication requests.
@end table

@menu
* Checking Duplicates::
* Proxying::
* Hints::
* Huntgroups::
* User Profiles::
@end menu

@comment **L3***************************************************************
@node Checking Duplicates
@subsection Checking for Duplicate Requests
@cindex duplicate requests, checking

As described above (@pxref{Operation}), a @NAS{} may decide to
retransmit the request under certain circumstances. This behavior
ensures that no requests are lost. For example, consider the following
scenario:

@enumerate
@item The @NAS{} sends a request to the server.
@item The server processes it and sends back the reply.
@item The reply is lost due to a network outage, or the load average of the
@NAS{} is too high and it drops the response.
@item The @NAS{} retransmits the request.
@end enumerate

Thus the @RADIUS{} server will receive and process the same request
twice. This probably won't do any harm if the request in question is an
authentication one, but for accounting requests it will lead to
duplicate accounting. To avoid such an undesirable effect, @radiusd{}
keeps a queue of received requests. When an incoming request arrives,
@radiusd{} first scans the request queue to see if the request is a
duplicate. If so, it drops the request; otherwise, it inserts the
request into the queue for processing. After the request is completed,
it will still reside in the queue for a preconfigured interval of time
(@pxref{auth}, parameter @code{request-cleanup-delay}).

By default, @radiusd{} considers two requests to be equal if the
following conditions are met:

@enumerate
@item Both requests come from the same @NAS{}.
@item They are of the same type.
@item The request identifier is the same for both requests.
@item The request authenticator is the same for both requests.
@end enumerate

Additionally, @radiusd{} may be configured to take into account the
contents of both requests. This may be necessary, since some @NAS{}es
modify the request authenticator or request identifier before
retransmitting the request, so the method described above fails to
recognize the request as a duplicate. This @dfn{extended comparison}
is described in detail in @ref{Extended Comparison}.

@comment **L3***************************************************************
@node Proxying
@subsection Proxying
@cindex Proxying

@dfn{Proxying} is a mode of operation where a @RADIUS{} server forwards
incoming requests from a @NAS{} to another @RADIUS{} server, waits for
the latter to reply, and then forwards the reply back to the
requesting @NAS{}. A common use for such operation mode is to provide
@dfn{roaming} between several internet service providers
(ISPs). Roaming permits ISPs to share their
resources, allowing  each party's users to connect to other party's
equipment. Thus, users traveling outside the area of one
ISP's coverage are still able to access their services
through another ISP.

@menu
* Proxy Service::
* Realms::
@end menu

@comment ***L4**************************************************************
@node Proxy Service
@subsubsection Proxy Service
@cindex Proxy Service

Suppose the ISP @samp{Local} has a roaming arrangement with
the ISP @samp{Remote}. When the user of @samp{Remote} dials
in to the @NAS{} of @samp{Local}, the @NAS{} sends the authentication
request to the @samp{Local} @RADIUS{} server. The server then
determines that this is a roaming user, stores a copy of the request
in its internal queue, and forwards the request to the @samp{Remote}
@RADIUS{} server for processing. Thus, the @samp{Local} @RADIUS{}
server acts as a client for the @samp{Remote} @RADIUS{} server.

When the @samp{Remote} @RADIUS{} server responds, the @samp{Local}
@RADIUS{} server receives the response, and passes it back to the
@NAS{}.  The copy of the request from the server's queue determines
which @NAS{} originated the request. Before passing the request back
to the @NAS{}, the server removes information specific to the
@samp{Remote} site, such as @attr{Framed-IP-Address},
@attr{Framed-Netmask}, etc. Only the attributes marked with a
@samp{propagation} flag (@pxref{Attributes}) are passed back to the
@NAS{}. After removing site-specific attributes, the @samp{Local}
@RADIUS{} server passes the request through its user profiles
(@pxref{User Profiles}) to insert any local, site-specific information
that might be needed. Finally, it passes the reply back to the @NAS{}.

Proxied accounting requests are processed in a similar manner, except
that no attribute filtering takes place, as accounting responses do not
carry any @AVP{}s.

This example illustrates only the simplest @dfn{proxy chain},
consisting of two servers; real-life proxy chains may consist of
several servers. For example, our @samp{Remote} @RADIUS{} server might
also act as a proxy, forwarding the request to yet another @RADIUS{}
server, and so on.

Note that when the accounting request passes through a chain of forwarding
servers, the accounting records are @emph{stored on all servers in the
chain}.

@comment ***L4**************************************************************
@node Realms
@subsubsection Realms
@cindex Realms

GNU Radius determines which server a request must be forwarded to by
the request's @dfn{authentication realm}. There are three kinds of
realms:

@enumerate 1
@item A @dfn{named realm} is the part of a user name following the
at sign (@samp{@@}). For example, if the user name is
@samp{jsmith@@this.net}, then @samp{this.net} is the realm.
The named realms can be cascaded; e.g., a request with user name
@samp{jsmith@@this.net@@remote.net} will first be forwarded to the
@RADIUS{} server of the realm @samp{remote.net}, which in turn will
forward it to @samp{this.net}.
@item A @dfn{default realm} defines the server to which the requests
for realms not mentioned explicitly in the configuration are forwarded.
@item An @dfn{empty realm} defines the server to which the requests
@emph{without} explicitly named realms are forwarded. If the
configuration does not define an empty realm, such requests are
processed by the server itself.
@end enumerate

GNU Radius keeps the information about the realms it serves in the
@file{raddb/realms} configuration file (@pxref{realms file}).

@comment **L3***************************************************************
@node Hints
@subsection Hints
@cindex Hints

@dfn{User-name hints} are special rules that modify the incoming
request depending on the user name and its credentials. Hints are
stored as a list of @dfn{matching rules} (@pxref{Matching Rule}). Upon
receiving a request, @radiusd{} scans the hint entries sequentially,
comparing each rule's label with the value of the
@attr{User-Name} attribute from the request. If they coincide, then
@radiusd{} appends the contents of the rule's @RHS{} to the request's
pair list.

The two user names must match exactly in order for a hint to take effect,
unless the hint's checklist contains either the @attr{Prefix} or the
@attr{Suffix} attribute. The special name @samp{DEFAULT} or
@samp{DEFAULT@var{%d}} (where @var{%d} denotes any decimal number),
used as a hint's
label, matches any user name.

Two special attributes, @attr{Prefix} and @attr{Suffix}, may be used
in @LHS{} to restrict the match to a specified part of a
user name. Both are string attributes. The @attr{Prefix} instructs
@radiusd{} to accept the hint only if the user name begins with the
given prefix. Similarly, @attr{Suffix} instructs @radiusd{} to accept
the hint only if the user name ends with the given suffix. A hint may
contain both @attr{Prefix} and @attr{Suffix} attributes.

In addition to these two attributes, a hint's @LHS{} may contain
@attr{User-ID} and @attr{Group} attributes.

The following attributes, when used in a hint's @RHS{} have special
meaning. They are not appended to the request pair list.  Instead,
they are removed after completing their function:
@table @attr
@item Fall-Through
If this attribute is present and is set to @code{Yes}, @radiusd{}
continues scanning the hints after processing the current entry. This
allows @radiusd{} to apply several hints to a single packet.
@item Rewrite-Function
If this attribute is present, the specified rewrite function is
invoked.
@item Replace-User-Name
The value of this attribute is expanded (@pxref{Macro Substitution})
and replaces the value of the @attr{User-Name} attribute from the
request.
@end table

Hint rules are defined in the @file{raddb/hints} file (@pxref{hints
file}).

@comment **L3***************************************************************
@node Huntgroups
@subsection Huntgroups
@cindex Huntgroups

Huntgroups are special rules that allow an administrator to provide
alternate processing of certain incoming requests depending on the
@NAS{} IP and port number they come from. These rules are stored as
a list of matching rules (@pxref{Matching Rule}).

Upon receiving a request, @radiusd{} scans this list sequentially
until it finds an entry such that the conditions set forth in its
@LHS{} are matched by the request. If such an entry is found,
@radiusd{} verifies that the request meets the conditions described by
@RHS{}. If it does not, the request is rejected. In short, a huntgroup
requires that any request matching its @LHS{} must match also its
@RHS{}.

The label part of the rule is not used in comparisons; instead
it is used to label huntgroups. All entries with the same label form a
single huntgroup. The special attribute @attr{Huntgroup-Name} can be
used to request a match against a particular huntgroup
(@pxref{Huntgroup-Name}).

Huntgroup rules are defined in the @file{raddb/huntgroups} file
(@pxref{huntgroups file}).

@comment **L3***************************************************************
@node User Profiles
@subsection User Profiles
@cindex User Profiles
@cindex Authentication

@dfn{User profiles} are @emph{per-user} matching rules
(@pxref{Matching Rule}). All incoming authentication requests are
compared with the user profiles after they have passed both
hints and huntgroups. @radiusd{} selects the user
profiles whose label matches the value of the @attr{User-Name}
attribute from the incoming request.

The selected profiles form the list of authentication rules for the
request. In order for a profile to be selected, its label must either
coincide literally with the @attr{User-Name} value, or be one
of the special labels, @code{DEFAULT} or @code{BEGIN}.

Rules in an authentication list are ordered as follows: first go all
the profiles with the @code{BEGIN} label, followed by the profiles whose
labels match the @attr{User-Name} literally, followed finally by the rules
labeled with the @code{DEFAULT}. @footnote{For compatibility with other
radius implementations, GNU Radius treats profile labels in the
form @code{DEFAULT@var{%d}}, where @var{%d} represents a decimal number, in
the same way it treats @code{DEFAULT} labels. The same applies to
@code{BEGIN} labels.}

Within each of the three sublists, the rules preserve the order in
which they appear in the @file{raddb/users} file. Once the list is
constructed, it is scanned sequentially until the rule is found whose
@LHS{} matches the incoming request. If no such rule is found, the
authentication fails. Otherwise, the contents of its @RHS{} are
appended to the reply list being constructed. If the @RHS{} of
the matched rule contains the attribute @attr{Fall-Through} with the
value @code{Yes}, the matching continues.  When the list is exhausted,
the authentication result is sent back to the @NAS{} along with the
@AVP{}s collected in the reply list.

User profiles are defined in the @file{raddb/users} file
(@pxref{users file}).