| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To illustrate what GNU Radius does, let's consider an imaginary internet service provider. Our provider has two network access servers (NASes 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 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 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 user session. For the purposes of 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.
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, NASes 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 client software to communicate with the RADIUS server by sending radius packets.
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.
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 acknowledgement packet, and then sends it back to the NAS
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 accounting start packet. The server acknowledges the receipt of the accounting packet.
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 accounting stop packet to the RADIUS server to mark this event. Again, the server acknowledges the receipt of the packet.
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 properties are associated with each attribute, specifying the way to interpret the attribute. The most important property is the data type, which declares the type of data that the attribute identifies (character string, integer number, IP address, or raw binary data).
The information to be transmitted with the request is packaged in a set of attribute-value pairs (or A/V pairs for short). Such pairs consist of attribute numbers and the associated data.
There exist two basic kinds of RADIUS packets: authentication and accounting packets. Each of them is subdivided into requests and replies.
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.
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 authentication acknowledgements, authentication rejections, and 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 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 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 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 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 retries are exhausted, whichever occurs first. Furthermore, a NAS may be configured to communicate with a set of 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.