The main purpose of Radius is to centralize authentication of users coming from various network stations. Its primary usage is for dial-in users, though it can be used for any kind of network connection.
Radius uses the Client/Server model. The main server keeps the centralized user database. Each user's profile in this database determines which services are allowed for this particular user.
The Network Access Server (NAS in short) is a machine that actually provides a service for the user. It can do so, e.g. by running a pool of modems the users can connect to. Otherwise, it can be a machine connected to the network and allowing some form of remote access, like telnet or ssh. It can even be a workstation allowing console logins to it. Whichever service it provides the NAS sends the request to the central Radius server in order to determine whether the user trying to access the service is allowed to do so. Such request carries information about user's login name, password, NAS identifier (such as its IP address), etc.
On receiving such request Radius server retrieves from its database a profile corresponding to the user's login name. The profile basically consists of two parts: a checklist used for authentication and a reply list used for authorization. The server checks the authenticity of the user using first part of the retrieved profile. If this check succeeds, it uses second part of the profile to authorize the user, i.e. to determine which service he should be provided. Then, the server responds with the parameters of the service, such as connection speed, framed IP address, etc. If any of the described checks had failed, the server sends the negative response.
If the server needs some additional information in order to process the request, it asks the NAS to supply such information. Thus, for example, if the user is allowed to use several services, he can be asked which one of them he wishes to use, etc.
When NAS receives the positive authentication response, it initiates the connection.
The NAS can be configured to notify Radius server about such events as session start, session stop or changing some parameters during the session. It can also notify the server about other events, such as NAS shutdown or startup. This is called accounting and the radius server responsible for processing this information is called an accounting server.
The information the Radius requests carry is stored as a list of Attribute-Value pairs. Each pair consists of Attribute number and Attribute value. The Attribute number identifies the type of information the pair carries and the Attribute Value keeps the actual data.
The Value part of an attribute can contain the data of one of the following types:
For convenience, the attributes and the values of some frequently used integer attributes are given symbolic names. These names are assigned to attributes and values in the dictionary file section Dictionary of Attributes -- `raddb/dictionary'.
The attribute numbers range from 1 to 255. The attributes with the numbers greater than 255 are used internally by the sever and cannot be sent to the NAS.
The special attribute 26, Vendor-Specific, is available to allow vendors of the NAS hardware or software to support their own extended attributes. section Vendor-Specific.
Each attribute has a set of properties associated with it. The properties are:
radiusd
scans the request to see if it already contains a pair with the same
attribute. If it does, the value of additivity determines the
further actions:
The attributes are declared in `raddb/dictionary' file. For a detailed description of it, See section ATTRIBUTE statement. For information about particular attributes, See section Attribute List.
The term request means both the authentication/accounting request from NAS to a Radius server and the response that the server sends back to the NAS.
Each request contains the following fields
A NAS sends authentication requests (packets with code Access-Request) to a RADIUS server when a user is trying to connect to that NAS. Such requests convey information used to determine whether a user is allowed access to the NAS, and any special services requested for that user.
An Access-Request must contain a User-Name attribute
section User-Name. It should contain either a NAS-IP-Address
attribute or NAS-Identifier attribute, or both of them.
It also must contain either a Password attribute or CHAP-Password
attribute. These attributes are passed encoded using a method based
on the RSA Message Digest Algorithm MD5.
The Access-Request should contain a NAS-Port or NAS-Port-Type
attribute or both unless the type of access being requested does
not involve a port or the NAS does not distinguish among its
ports.
Upon receiving Access-Request packet for a particular user and authenticating that user, Radius server replies to the NAS that has sent the packet with either of the following packets:
Radius replies with Access-Accept packet when it has successfully authenticated the user. Such reply packet provides specific configuration information necessary to begin delivery of service to the user.
Radius replies with Access-Reject packet when it was unable to
authenticate the user. Such packet may contain a descriptive
text encapsulated in one or more Reply-Message attributes.
The NAS may display this text along with its response to the
user.
Radius replies with Access-Challenge packet when it desires to obtain more information from the user in order to determine its authenticity or to determine the kind of service to be provided to the user.
An Access-Challenge packet may include one or more Reply-Message
attributes, and may also include a single State attribute, or
none. No other Attributes are permitted in an Access-Challenge.
On receipt of an Access-Challenge, the Identifier field is matched with a pending Access-Request. Additionally, the Response Authenticator field must contain the correct response for the pending Access-Request. Radius discards invalid packets and issues appropriate log message.
If the NAS does not support challenge/response, it treats an
Access-Challenge as though it had received an Access-Reject instead.
Otherwise, upon receipt of a valid Access-Challenge the NAS prompts the
user for a response, possibly displaying the text message provided in
Reply-Message attributes of the request. It then sends its
original Access-Request with a new request ID and Request Authenticator,
with the Password attribute replaced by the encrypted user's
response, and including the State attribute from the
Access-Challenge, if any.
Accounting-Request packets are sent from a NAS to a Radius server to allow for accounting of a service provided to a user.
Upon receipt of an Accounting-Request, the server attempts to record the accounting packet section Accounting, and if it succeeds in doing so it replies with an Accounting-Response packet. Otherwise it sends no reply, which then causes the NAS to retransmit its request within a preconfigured interval of time. Such retransmits will continue until either the server responds with an Accounting-Response packet or a preconfigured number of retransmits is reached, whichever occurs first.
Any attribute valid in an Access-Request or Access-Accept packet is also valid in an Accounting-Request packet, except the following attributes, which are never present in an Accounting-Request packet:
Either NAS-IP-Address or NAS-Identifier must be present in an
Accounting-Request. It should contain a NAS-Port or
NAS-Port-Type attribute or both unless the service does not involve a
port or the NAS does not distinguish among its ports.
If the Accounting-Request packet includes a Framed-IP-Address, that attribute must contain the actual IP address of the user.
There are five types of accounting packets, which differ by the value of
Acct-Status-Type attribute. These are:
A record in the radius database describing a particular rule for matching an incoming request is called a Matching Rule. Each such rule defines an action to be taken when the match occurs.
The Matching Rule consists of three distinct parts:
DEFAULT
and BEGIN are reserved. These will be described in detail below.
The following radius configuration files keep data in a Matching Rule format: `hints', `huntgroups' and `users'. Although they keep data in similar format, the rules that are used to match incoming requests against contents of these files differ from file to file. The following section describes these rules in detail.
Upon receiving a request Radius 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:
User-Name attribute it is not processed
Password attribute.
Proxying is a mode of operation when a radius server forwards an incoming requests from a NAS to another radius server, waits for the latter to reply, and 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 the ISPs to share their resources, allowing each other'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.
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 `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 `Remote' radius
server for processing. Thus, `Local' radius acts as a client for
`Remote' radius. When `Remote' radius responds, the
`Local' receives the response, and passes it back to the NAS.
The copy of the request from the server's queue serves to determine
which NAS originated the request. Before passing the request
back to the NAS, radius removes from it the information,
specific for `Remote' site, such as Framed-IP-Address,
Framed-Netmask, etc. Only the attributes marked with
`propagate' flag (see section Attributes) are passed back to
the NAS. After removing site-specific attributes, `Local' radius
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.
The accounting requests are processed in the similar manner, except that no attribute filtering takes place, as the accounting responces do not carry any A/V pairs.
This example illustrates the simplest proxy chain, consisting of only two servers. The proxy chains may consist of several servers. In our example, the `Remote' radius server may also act as a proxy and forward the request to still another radius server, etc.
Note, that when the accounting request passes through a chain of forwarding servers, the accounting records are stored on all servers in the chain.
Radius server determines which server a request must be forwarded to by request's authentication realm. There are three kinds of realms:
GNU Radius keeps the information about the realms it serves in configuration file `raddb/realms' (see section List of Proxy Realms -- `raddb/realms').
User-name hints are special rules that modify the incoming request
depending on user name and his credentials. Hints are stored as a list
of Matching Rules (see section Matching Rule). Upon receiving a request,
radiusd scans the hints entries sequentially, comparing each
rule's Label with the value of User-Name attribute from
the request. If they coincide, then radiusd appends the contents
of the rule's RHS to the request pair-list.
Both user names must match exactly in order for a hint to
take effect, unless the hint's checklist contains either Prefix or
Suffix attribute. The special name `DEFAULT' or
`DEFAULT%d' (where %d denotes any decimal number), used as hint's
Label match any username.
The 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 radius to accept the
hint only if the username begins with the given prefix. Similarly,
Suffix instructs radius to accept the hint only if the username
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
Yes, radiusd
continues scanning the hints, after processing current entry. This
allows for applying several hints to a single packet.
Rewrite-Function
Replace-User-Name
User-Name attribute from the request.
The hints rules are defined in `raddb/hints' file (see section Request Processing Hints -- `raddb/hints').
Huntgroups are special rules, that allow to alter processing of incoming
requests, depending on NAS IP address and port number they come
from. The 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 meet 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).
The huntgroups rules are defined in `raddb/huntgroups' file (see section Huntgroups -- `raddb/huntgroups').
User Profiles are the per-user matching rules
(see section Matching Rule). Any incoming authentication request is compared
with the User Profiles after it has passed both Hints and
Huntgroups. Radiusd selects from the User Profiles
those rules, whose Label matches the value of 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
it must be one of special labels DEFAULT and BEGIN.
The rules in the authentication list are ordered as follows: first
go all the profiles with BEGIN label, they are followed
by the profiles, whose labels match the User-Name literally,
and, finally, these are followed by rules labeled with DEFAULT.
(1) Within each of the
three sub-lists the rules preserve the order in which they appear in
`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, then the authentication
fails. Otherwise, the contents of its RHS is appended to Reply
List being constructed. If the RHS of the matched rule contains 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.
The user profiles are defined in `raddb/users' file (see section User Profiles -- `raddb/users').
Go to the first, previous, next, last section, table of contents.