The RADIUS protocol follows client-server architecture.
The client sends user information to the RADIUS AAA server (in an
Access-Request message). After receiving a reply from the
server, the client acts according to the returned information.
The RADIUS AAA server performs the following functions:
Receive user
requests for access from the client
Attempt to authenticate the
user
Return configuration information,
and policies to the client
The RADIUS AAA server can be configured to authenticate an Access-Request
locally or to act as a proxy client and forward a request to another
AAA server. After forwarding a request, the AAA server handles the
message exchanges between the NAS and the remote server. A single server
can be configured to handle some requests locally, and to forward proxy
requests to remote servers.
In Figure 1-1 “Generic AAA Network Topology”, an example
Internet Service Provider (ISP) uses four AAA servers to handle
user requests. Each user organization represents a logical grouping
of users (defined as a realm). Each user organization dials in to
one of the ISP’s servers through an assigned NAS, some
of which are shared by the same groups or realm. To provide appropriate service
to a customer, the server accesses user and policy information from
a repository. This repository can be integrated with the server,
may be an external application, or a database that interfaces with
the server. For the HP-UX AAA RADIUS server the repository
information can be stored in flat text files or in an external database,
such as an Oracle® database
or LDAP directory server.
When authenticating users stored in replicated LDAP directory
servers or Oracle databases, the server performs load balancing
and failover functions. Load balancing assigns a number of requests
(determined by authentication type) to one server and assigns each
subsequent set of requests to a different server. Failover keeps
track of each pending request's age and after a built-in
time interval moves the request to a different server's queue. Both
functions assign requests in a round robin fashion — they
find the next available server to communicate with and that has
space available in its request queue.
Printable version
