Using RADIUS

Making use of a single database of accessible information - as in an Authentication Server - can greatly simplify the authentication and management of users in a large network. One such type of Authentication Server supports the Remote Authentication Dial-In User Service (RADIUS) protocol as defined by RFC 2865.

For authenticating users prior to access, the RADIUS standard has become the protocol of choice by administrators of large accessible networks. To accomplish the authentication in a secure manner, the RADIUS client and RADIUS server must both be configured with the same shared password or secret. This secret is used to generate one-way encrypted authenticators that are present in all RADIUS packets. The secret is never transmitted over the network.

RADIUS conforms to a secure communications client/server model using UDP as a transport protocol. It is extremely flexible, supporting a variety of methods to authenticate and statistically track users. RADIUS is also extensible, allowing for new methods of authentication to be added without disrupting existing functionality.

As a user attempts to connect to a functioning RADIUS supported network, a device referred to as the Network Access Server (NAS) or switch/router first detects the contact. The NAS or user-login interface then prompts the user for a name and password. The NAS encrypts the supplied information and a RADIUS client transports the request to a preconfigured RADIUS server. The server can authenticate the user itself, or make use of a back-end device to ascertain authenticity. In either case a response might or might not be forthcoming to the client. If the server accepts the user, it returns a positive result with attributes containing configuration information. If the server rejects the user, it returns a negative result. If the server rejects the client or the shared secrets differ, the server returns no result. If the server requires additional verification from the user, it returns a challenge, and the request process begins again.

RADIUS Configuration Example

This example configures two RADIUS servers at 10.10.10.10 and 11.11.11.11 (see FIGURE B-1). Each server has a unique shared secret key. The shared secrets are configured to be secret1 and secret2 respectively. The server at 10.10.10.10 is configured as the primary server. (See CODE EXAMPLE B-1 for RADIUS configuration commands used for this example.) The process creates a new authentication list, called radiusList, which uses RADIUS as the primary authentication method, and local authentication as a backup method in the event that the RADIUS server cannot be contacted. This authentication list is then associated with the default login.

When a user attempts to log in, the switch prompts for a username and password. The switch then attempts to communicate with the primary RADIUS server at 10.10.10.10. Upon successful connection with the server, the login credentials are exchanged over an encrypted channel. The server grants or denies access, which the switch honors, and either allows or does not allow the user to access the switch. If neither of the two servers can be contacted, the switch searches its local user database for the use.

CODE EXAMPLE B-1 RADIUS Configuration Example
`config` `radius server host auth 10.10.10.10` `radius server key auth 10.10.10.10` `secret1` `secret1` `radius server host auth 11.11.11.11` `radius server key auth 11.11.11.11` `secret2` `secret2` `radius server primary 10.10.10.10` `authentication login radiusList radius local` `users defaultlogin radiusList` `exit`

CODE EXAMPLE B-1 RADIUS Configuration Example

config
    radius server host auth 10.10.10.10
    radius server key auth 10.10.10.10	  
      secret1
      secret1
    radius server host auth 11.11.11.11	 
    radius server key auth 11.11.11.11
      secret2
      secret2
    radius server primary 10.10.10.10
    authentication login radiusList radius local
    users defaultlogin radiusList
exit