RADIUS is an industry-standard protocol for providing authentication, authorization, and accounting services.
Authentication is the process of verifying a user’s identity and associating additional information (attributes) to the user’s login session.
Authorization is the process of determining whether the user is allowed on the network and controlling network access values based on a defined security policy.
Accounting is the process of generating log files that record session statistics used for billing, system diagnosis, and usage planning.
A RADIUS-based remote access environment typically involves four types of components:
An access client is a user who initiates a network connection. An access client might be a user dialing into a service provider network, a router at a small office/home office connecting to an enterprise network to provide network access, or a wireless client connecting to an 802.1X access point.
A network access server (NAS), also called a RADIUS client, is a device that recognizes and processes connection requests from outside the network edge. A NAS can be a wireless access point, a modem pool, a network firewall, or any other device that needs to authenticate users. When the NAS receives a user’s connection request, it may perform an initial access negotiation with the user to obtain identity/password information. The NAS then passes this information to the RADIUS server as part of an authentication/authorization request.
The terms network access device (NAD), remote access server (RAS), and network access server (NAS) are interchangeable. This guide primarily uses the term NAS.
The RADIUS server matches data from the authentication/authorization request with information in a trusted database, such as the database on the Steel-Belted Radius Carrier server or a back-end database server. If a match is found and the user’s credentials are correct, the RADIUS server sends an Access-Accept message to the NAS. If a match is not found or a problem is found with the user’s credentials, the server returns an Access-Reject message. The NAS then establishes or terminates the user’s connection. The NAS may then forward accounting information to the RADIUS server to document the transaction; the RADIUS server may store or forward this information as needed to support billing for the services provided.
In some networks, a back-end authentication server, such as SQL or LDAP database; or some other RADIUS server for which this server is a proxy, stores the information against which the authentication request is compared. In some cases, the back-end server passes information to the RADIUS server, which determines whether a match exists. In other cases, the matching is performed on the back-end server, which then passes an accept/reject result to the RADIUS server.
Figure 12 illustrates a simple RADIUS environment.
A RADIUS client and RADIUS server communicate by means of RADIUS packets. RADIUS packets carry messages between the RADIUS client and RADIUS server in a series of request/response transactions: the client sends a request and expects a response from the server. If the response does not arrive, the client can retry the request periodically.
Each RADIUS packet supports a specific purpose: authentication or accounting. A packet can contain values called attributes. The specific attributes to be found in each packet depend upon the type of packet (authentication or accounting) and the device that sent it (for example, the specific make and model of the NAS acting as a RADIUS client).
For information about RADIUS authentication packet structures and attributes, see RFC 2865, Remote Authentication Dial-In User Service (RADIUS). For information about RADIUS accounting packet structures and attributes, see RFC 2866, RADIUS Accounting.
Figure 13 illustrates a simple RADIUS authentication/authorization sequence.
The RADIUS access client sends an authentication request containing identification and connection information to the network access server (RADIUS client).
When the NAS receives a user’s connection request, it typically performs an initial access negotiation with the user to establish connection information (username, password, network access server identifier, NAS port number, and so on). The NAS then forwards the user information in an authentication request to the RADIUS server.
The RADIUS server looks up the user information in a local or remote RADIUS authentication database. The RADIUS server verifies that the user’s name and password are valid. It can also enforce fine-grained security rules by using an access check list to verify specific attributes in the authentication request.
If a match is found, the RADIUS server returns an Access-Accept message. The RADIUS server might also send return list information stored in the database, such as the user’s authorization or connection parameters, back to the NAS.
If a match is not found, the RADIUS server returns an Access-Reject message.
Based on the information it receives from the RADIUS server, the NAS accepts or refuses the connection request.
After the user is authenticated and the connection established, the NAS may forward accounting data to the RADIUS server to document the transaction; the RADIUS server can store or forward this data to support billing for the services provided.
The RADIUS standard initially used UDP ports 1645 and 1646 for RADIUS authentication and accounting packets. The RADIUS standards group later changed the port assignments to 1812 and 1813, but many organizations still use the old 1645/1646 port numbers for RADIUS.
Any two devices that exchange RADIUS packets must use compatible UDP port numbers. That is, if you are configuring a NAS to exchange authentication packets with a RADIUS server, you must find out which port the server uses to receive authentication packets from its clients (1812, for example). You must then configure the NAS to send authentication packets on the same port (1812). The same is true for RADIUS accounting.
Steel-Belted Radius Carrier can listen on multiple ports. For compatibility, the server listens to the old and new default RADIUS ports: ports 1645 and 1812 for authentication, and ports 1646 and 1813 for accounting. To add, change, or disable the ports on which Steel-Belted Radius Carrier listens, modify the radius.ini file or edit the /etc/services file. The radius.ini file is described in the SBR Carrier Reference Guide.
You must configure a RADIUS client and RADIUS server before they can communicate. If the client and server are on the same network, one administrator may be able to configure both sides of the RADIUS communication. If the client and server are not administered by the same person, you may have to coordinate RADIUS configuration details with the administrators of other networks.
RADIUS Server Configuration
RADIUS Server Configuration
To configure Steel-Belted Radius Carrier to respond to RADIUS clients, open the RADIUS Clients List page in Web GUI and enter the following information for each RADIUS client:
The IP address of the client device.
The RADIUS shared secret used by Steel-Belted Radius Carrier and the client device. For information about RADIUS shared secrets, see Shared Secrets.
The make and model of the client device, selected from a list of devices that Steel-Belted Radius Carrier supports. If a specific make and model is not listed, select - Standard Radius -.
Additionally, you must configure the UDP ports the server uses when sending and receiving RADIUS authentication and accounting packets. The UDP ports you configure on the RADIUS server must match the UDP ports that the RADIUS client is using for the same purposes. For more information, see RADIUS Ports.
RADIUS Client Configuration
RADIUS Client Configuration
You must tell each RADIUS client how to contact its RADIUS server. To configure a client to work with a Steel-Belted Radius Carrier server, log in to the client device, run its administration program, bring up its RADIUS configuration interface, and enter the following information:
The IP address of the Steel-Belted Radius Carrier server.
The RADIUS shared secret to be used by Steel-Belted Radius Carrier and the client device. For information about RADIUS shared secrets, see Shared Secrets.
The UDP ports on which to send and receive RADIUS authentication and accounting packets. These must match the UDP ports that Steel-Belted Radius Carrier is using for the same purposes. For more information, see RADIUS Ports.
Multiple RADIUS Servers
Multiple RADIUS Servers
You can distribute the RADIUS workload among several servers, as follows:
You can set up separate servers for RADIUS authentication and accounting services. When RADIUS authentication and accounting services are performed by separate servers, each client device must be configured to send its authentication packets to one RADIUS server and its accounting packets to another.
You can provide redundancy by pairing RADIUS servers to work in tandem. Most NAS configuration interfaces permit you to designate primary and secondary servers for authentication and accounting.
If both measures for distributing the RADIUS workload are implemented, client configuration involves identifying four servers for each client device: a primary RADIUS accounting server, a secondary RADIUS accounting server, a primary RADIUS authentication server, and a secondary RADIUS authentication server.
A shared secret is a case-sensitive text string used to validate communications between two RADIUS devices. You should configure shared secrets that are long enough and random enough to resist attack, and you should avoid using the same shared secret throughout your network.
Steel-Belted Radius Carrier uses the following types of shared secrets:
RADIUS secret—Used to authenticate communication between a RADIUS server and a RADIUS client
Replication secret—Used to authenticate communication between a primary server and a replica server
Figure 14 illustrates the usage of shared secrets in a RADIUS environment.
A RADIUS shared secret is a case-sensitive password used to validate communications between a RADIUS server such as Steel-Belted Radius Carrier, and a RADIUS client, such as a network access server. Steel-Belted Radius Carrier supports shared secrets of up to 127 alphanumeric characters, including spaces and the following special characters:
Identical shared secrets must be configured on both sides of the RADIUS communication link.
Not all network access servers support shared secrets of up to 127 alphanumeric/special characters. Select shared secrets that are fully supported by RADIUS devices in your network.
Most RADIUS clients allow you to configure different secrets for authentication and accounting. On the server side, the configuration interface allows you to create a list of known RADIUS clients (network access servers). You can usually identify the authentication shared secret and accounting shared secret that a server uses to communicate with each of the clients on this list.
During an authentication transaction, password information must be transmitted securely between the RADIUS client (network access server) and Steel-Belted Radius Carrier. Steel-Belted Radius Carrier uses the authentication shared secret to encrypt and decrypt password information.
No encryption is involved in transmitting accounting data between a RADIUS client and RADIUS server. However, the accounting shared secret is used by each device to verify that it can trust any RADIUS communications it receives from the other device.
A replication secret is a text string used to authenticate communications between a primary server and a replica server. You do not need to configure the replication secret for a realm: the primary server generates it automatically, and each replica server in a realm receives the replication secret as part of its configuration package.
See Overview of Replication for information about primary and replica servers.
A NAS can issue an Accounting-Request whenever it chooses, for example upon establishing a successful connection. Each time an Accounting-Request message arrives at the Steel-Belted Radius Carrier server, an accounting transaction begins. During this transaction, the server handles the message by examining the Acct-Status-Type and other attributes within the message, and taking the appropriate action.