[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section Logging).
The following checks are performed:
If the packet lacks the User-Name
attribute, it is not processed.
The source IP of the machine that sent the packet is looked up in the ‘clients’ file (see section Clients List — ‘raddb/clients’). If no match is found, the request is rejected.
Using the data from the packet and the shared key value from the
‘clients’ file, Radius computes the MD5 encryption key that will
be used to decrypt the value of the User-Password
attribute.
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 ‘raddb/hints’ (see section Request Processing Hints — ‘raddb/hints’).
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 ‘raddb/huntgroups’ (see section Huntgroups — ‘raddb/huntgroups’).
The requests pertaining to another realm are immediately forwarded to the remote RADIUS server for further processing. See section Proxying, for the description of this process.
This step applies only to authentication requests.
2.4.1 Checking for Duplicate Requests | ||
2.4.2 Proxying | ||
2.4.3 Hints | ||
2.4.4 Huntgroups | ||
2.4.5 User Profiles |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As described above (see section How Radius Operates), 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:
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
(see section auth
statement, parameter request-cleanup-delay
).
By default, radiusd
considers two requests to be equal if the
following conditions are met:
Additionally, radiusd
may be configured to take into account the
contents of both requests. This may be necessary, since some NASes
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 extended comparison
is described in detail in Extended Comparison.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 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.
2.4.2.1 Proxy Service | ||
2.4.2.2 Realms |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suppose the ISP ‘Local’ has a roaming arrangement with the ISP ‘Remote’. When the user of ‘Remote’ dials in to the NAS of ‘Local’, the NAS sends the authentication request to the ‘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 ‘Remote’ RADIUS server for processing. Thus, the ‘Local’ RADIUS server acts as a client for the ‘Remote’ RADIUS server.
When the ‘Remote’ RADIUS server responds, the ‘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
‘Remote’ site, such as Framed-IP-Address
,
Framed-Netmask
, etc. Only the attributes marked with a
‘propagation’ flag (see section Attributes) are passed back to the
NAS. After removing site-specific attributes, the ‘Local’
RADIUS server passes the request through its user profiles
(see section 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 A/V pairs.
This example illustrates only the simplest proxy chain, consisting of two servers; real-life proxy chains may consist of several servers. For example, our ‘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 stored on all servers in the chain.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Radius determines which server a request must be forwarded to by the request's authentication realm. There are three kinds of realms:
GNU Radius keeps the information about the realms it serves in the ‘raddb/realms’ configuration file (see section List of Proxy Realms — ‘raddb/realms’).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 matching rules (see section Matching Rule). Upon
receiving a request, radiusd
scans the hint entries sequentially,
comparing each rule's label with the value of the
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 Prefix
or the
Suffix
attribute. The special name ‘DEFAULT’ or
‘DEFAULT%d’ (where %d denotes any decimal number),
used as a hint's
label, matches any user name.
Two special attributes, Prefix
and Suffix
, may be used
in LHS to restrict the match to a specified part of a
user name. Both are string attributes. The Prefix
instructs
radiusd
to accept the hint only if the user name begins with the
given prefix. Similarly, Suffix
instructs radiusd
to accept
the hint only if the user name ends with the given suffix. A hint may
contain both Prefix
and Suffix
attributes.
In addition to these two attributes, a hint's LHS may contain
User-ID
and 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:
Fall-Through
If this attribute is present and is set to Yes
, radiusd
continues scanning the hints after processing the current entry. This
allows radiusd
to apply several hints to a single packet.
Rewrite-Function
If this attribute is present, the specified rewrite function is invoked.
Replace-User-Name
The value of this attribute is expanded (see section Macro Substitution)
and replaces the value of the User-Name
attribute from the
request.
Hint rules are defined in the ‘raddb/hints’ file (see section Request Processing Hints — ‘raddb/hints’).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section 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 Huntgroup-Name
can be
used to request a match against a particular huntgroup
(see section Huntgroup-Name
).
Huntgroup rules are defined in the ‘raddb/huntgroups’ file (see section Huntgroups — ‘raddb/huntgroups’).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
User profiles are per-user matching rules
(see section 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 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 User-Name
value, or be one
of the special labels, DEFAULT
or BEGIN
.
Rules in an authentication list are ordered as follows: first go all
the profiles with the BEGIN
label, followed by the profiles whose
labels match the User-Name
literally, followed finally by the rules
labeled with the DEFAULT
. (1)
Within each of the three sublists, the rules preserve the order in
which they appear in the ‘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 Fall-Through
with the
value Yes
, the matching continues. When the list is exhausted,
the authentication result is sent back to the NAS along with the
A/V pairs collected in the reply list.
User profiles are defined in the ‘raddb/users’ file (see section User Profiles — ‘raddb/users’).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.