intro.texi

gnu 的radius服务器很好用的

@c This is part of the GNU Radius manual.
@c Copyright (C) 2003 Free Software Foundation
@c See file radius.texi for copying conditions.
@comment *******************************************************************
@node Intro, Naming Conventions, Top, Top
@unnumbered Introduction to Radius

GNU Radius is a software package that provides authentication and
accounting services.  The acronym @RADIUS{} stands for @dfn{Remote
Authentication Dial In User Service} and (in that form) usually denotes the
underlying protocol name.

Historically, @RADIUS{} servers were used as a means to authenticate the user
coming from a dial-in connection, but GNU Radius is much more than an
authentication system: it is an advanced, customizable, and extensible system
for controlling access to the network.

GNU Radius has several built-in authentication and accounting methods.
When these methods are not enough, it allows the administrator to implement
any new method she deems convenient. 

The GNU Radius package includes the server program,
@radiusd{}, which responds to authentication and accounting requests,
and a set of accompanying programs designed to monitor the activity of
the server and analyze the information it provides.

@menu
* Overview::
@end menu

@comment *******************************************************************
@node Overview
@section Overview

To illustrate what GNU Radius does, let's consider an imaginary internet
service provider.  Our provider has two @dfn{network access servers}
(@NAS{}es for short)---i.e., two pieces of equipment which directly accept
users' connections---and a core router that connects the ISP's internal
network with the Internet backbone.

When a user connects to a @NAS{}, the server must verify that the
user is actually registered and that the credentials she has
supplied are correct.  This first step is called
@dfn{authentication}.

Upon authenticating the user, the @NAS{} must determine which services
the user is permitted to use and to what extent the user may use
them.  This second step is called @dfn{authorization}.

When the first two stages have been successfully completed, the @NAS{}
takes the third step and establishes the connection between the user
and the main server.  This connection is called a @dfn{user session}.
For the purposes of @dfn{accounting}, the @NAS{} remembers the exact
time of the start of the session.  When the session is terminated, the
duration of the session and the number of bytes transferred are
recorded as well.

All three tasks can be accomplished by the use of user and accounting
databases on each terminal server.  However, this is not convenient,
and it is error-prone in that the maintenance of separate databases for
the same users is not a trivial task.  What is worse, as the number of
terminal servers grows, this maintenance problem
becomes more difficult.

@subheading How Does @RADIUS{} Perform These Tasks?

@RADIUS{} allows an administrator to keep authentication and
accounting data in a single place, no matter how many network access
servers are actually present.  Using @RADIUS{}, @NAS{}es instead
communicate with this central server to perform authentication and
accounting, thus easing the burden on the system administrator.

Let's return to our imaginary ISP.  Suppose it runs a @RADIUS{} daemon
on its central server.  Each @NAS{} runs @dfn{client software} to
communicate with the @RADIUS{} server by sending @dfn{radius packets}.

@c @image{isp} 

An average user session life cycle looks as follows.

A user connects to the nearest @NAS{} and supplies his login and
password.  The @NAS{} forms an authentication request and sends it to
the @RADIUS{} server.

@c @image{authreq}

The @RADIUS{} server verifies the user's credentials and finds them
sufficient.  It then retrieves the user's authorization information
from its database, packages it into an @dfn{acknowledgement packet},
and then sends it back to the @NAS{}

@c @image{authack}

The @NAS{} receives the acknowledgement packet and starts the user
session.  The information brought with the packet tells the @NAS{} to
establish a connection between the core router and the user, and to
assign the user a certain IP address.  Having established the session,
the @NAS{} informs the @RADIUS{} server by sending it an
@dfn{accounting start packet}.  The server acknowledges the receipt of
the accounting packet.

@c @image{acctstart}

Now suppose that after some time the user decides to break the
connection.  The @NAS{} notices this and terminates the user's
session.  The @NAS{} then sends an @dfn{accounting stop packet} to the
@RADIUS{} server to mark this event.  Again, the server acknowledges
the receipt of the packet.

@c @image{acctstop}

@subheading @RADIUS{} Attributes

@dfn{Attributes} are means of passing the information between the
@NAS{} and the server.  Basically, an attribute is an integer number
that identifies some piece of information.  A set of @dfn{properties}
are associated with each attribute, specifying the way to interpret
the attribute.  The most important property is the @dfn{data type}, which
declares the type of data that the attribute
identifies (@dfn{character string}, @dfn{integer number}, @dfn{IP
address}, or @dfn{raw binary data}).

The information to be transmitted with the request is packaged in a
set of @dfn{attribute-value pairs} (or @AVP{}s for short).  Such pairs
consist of attribute numbers and the associated data.

@subheading @RADIUS{} Packets

There exist two basic kinds of @RADIUS{} packets: authentication and
accounting packets.  Each of them is subdivided into @dfn{requests} and
@dfn{replies}.

@dfn{Authentication requests} are sent from the @NAS{} to the
@RADIUS{} server and contain the information necessary to check the
identity of the user.  The minimum set of data in such packets
consists of the
user login name, user password, and @NAS{} IP or identifier.

@dfn{Authentication replies} are sent by the @RADIUS{} server and
contain the reply code and a set of additional attributes.  According
to their
reply code the authentication replies are subdivided into
@dfn{authentication acknowledgements}, @dfn{authentication rejections},
and @dfn{authentication challenges}.

An authentication acknowledgement packet is sent to the @NAS{} if the
credentials supplied with the authentication request were
correct.  This kind of packet tells the @NAS{} to establish a normal
user session.  The additional attributes in such packets carry
the @dfn{authorization data}, i.e., they determine which kind of
service the user is to be provided.

An authentication rejection is sent to the @NAS{} if the
authentication has
failed.  This packet forbids the @NAS{} to provide any service to
the user.  The additional attributes may carry descriptive text to be
displayed as an explanation to the user for the failure of his request.

Finally, an authentication challenge packet is sent to the @NAS{} if
the supplied credentials did not suffice to establish the authenticity
of the user.  This means that the dialog between the @NAS{} and the
@RADIUS{} server continues.  As the @RADIUS{} server asks for
additional authentication credentials, the @NAS{} acts as a
liaison, passing server requests to the user and sending user
replies back to the server.  Such a dialog ends when the @RADIUS{}
server sends
either an acknowledgement packet or a rejection packet.

An @dfn{accounting request} is sent to the server when the @NAS{}
wishes to report some event in the user session: the start of the
session, session termination, etc.  The attributes carry the actual
information about the event.

For each accounting request that has been received and successfully
processed, the @RADIUS{} server sends back an @dfn{accounting
acknowledgement}.  This packet carries no attributes, but simply informs
the @NAS{} that the information it had sent was received.

Occasionally, a @RADIUS{} server may fail to receive incoming requests or may
fail to process them due to high server load.  In order to prevent
such requests from being lost, the @NAS{} retransmits the request
if no response from the server is received within a
predefined interval of time (a @dfn{timeout} interval).  Usually the
@NAS{} is configured in such a way that it continues retransmitting
failed requests until either it receives a reply from the server
or a predefined number of @dfn{retries} are exhausted, whichever
occurs first.  Furthermore, a @NAS{} may be configured to communicate
with a set
of @dfn{backup} @RADIUS{} servers.  In this case it applies the described
process to each server from the set, until one of them responds or
the set is exhausted.