2.4 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 (see section Logging).

The following checks are performed:

Check if the username is supplied.

If the packet lacks the User-Name attribute, it is not processed.

Check if the NAS is allowed to speak.

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.

Compute the encryption key.

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.

Process user-name hints.

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’).

Process huntgroup rules.

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’).

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. See section Proxying, for the description of this process.

Process individual user profiles

This step applies only to authentication requests.

2.4.1 Checking for Duplicate Requests

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:

1. The NAS sends a request to the server.
2. The server processes it and sends back the reply.
3. The reply is lost due to a network outage, or the load average of the NAS is too high and it drops the response.
4. The NAS retransmits the request.

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:

1. Both requests come from the same NAS.
2. They are of the same type.
3. The request identifier is the same for both requests.
4. The request authenticator is the same for both requests.

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.

2.4.2 Proxying

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

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.

2.4.2.2 Realms

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

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

GNU Radius keeps the information about the realms it serves in the ‘raddb/realms’ configuration file (see section List of Proxy Realms — ‘raddb/realms’).

2.4.3 Hints

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’).

2.4.4 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 (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’).

2.4.5 User Profiles

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’).

This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.