|
|
Cisco Access Registrar is a RADIUS (Remote Authentication Dial-In User Service) server that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.
Cisco Access Registrar handles the following tasks:
Using a RADIUS server allows you to better manage the access to your network, as it allows you to store all security information in a single, centralized database instead of distributing the information around the network in many different devices. You can make changes to that single database instead of making changes to every network access server in your network.
Cisco Access Registrar is based on a client/server model, which supports AAA (authentication, authorization, and accounting). The client is the Network Access Server (NAS) and the server is Cisco Access Registrar. The client passes user information on to the RADIUS server and acts on the response it receives. The server, on the other hand, is responsible for receiving user access requests, authenticating users, and returning all of the necessary configuration information the client can then pass on to the user.
The protocol is a simple packet exchange in which the NAS sends a request packet to the Cisco Access Registrar with a name and a password. Cisco Access Registrar looks up the name and password to verify it is correct, and then returns an accept packet that contains configuration information for the user session (Figure 1-1).
Cisco Access Registrar can also reject the packet if it needs to deny network access to the user. Or, Cisco Access Registrar may issue a challenge that the NAS sends to the user, who then creates the proper response and returns it to the NAS, which forwards it to Cisco Access Registrar in a second request packet.
In order to ensure network security, the client and server use a shared secret, which is a password they both know, but which is never sent over the network. User passwords are also encrypted between the client and the server to protect the network from unauthorized access.
Three participants exist in this interaction: the user, the NAS, and the RADIUS server. The following steps describe the receipt of an access request through the sending of an access response. For more information, see the "Program Flow" section.
Step 1 The user, at a remote location such as a branch office or at home, dials into the NAS, and supplies a name and password.
Step 2 The NAS picks up the call and begins negotiating the session.
(a) The NAS receives the name and password.
(b) It formats this information into an Access-Request packet.
(c) It sends the packet on to the Cisco Access Registrar server.
Step 3 The Cisco Access Registrar server determines what hardware sent the request (NAS) and parses the packet.
(a) It sets up the Request dictionary based on the packet information.
(b) It runs any incoming scripts, which are user-written extensions to Cisco Access Registrar. An incoming script can examine and change the attributes of the request packet or the environment variables, which can affect subsequent processing.
(c) Based on the scripts or the defaults, it chooses a service to authenticate and/or authorize the user.
Step 4 Cisco Access Registrar's authentication service verifies the username and password is in its database. Or, Cisco Access Registrar delegates the authentication (as a proxy) to another RADIUS server, an LDAP, or TACACS server.
Step 5 Cisco Access Registrar's authorization service creates the response with the appropriate attributes for the user's session and puts it in the Response dictionary.
Step 6 If you are using Cisco Access Registrar session management at your site, the Session Manager calls the appropriate Resource Managers that allocate dynamic resources for this session.
Step 7 Cisco Access Registrar runs any outgoing scripts to change the attributes of the response packet.
Step 8 Cisco Access Registrar formats the response based on the Response dictionary and sends it back to the client (NAS).
Step 9 The NAS receives the response and communicates with the user, which may include sending the user an IP address to indicate the connection has been successfully established.
The client/server packet exchange consists of the following types of RADIUS messages:
When you use RADIUS accounting, the client and server can also exchange the following two types of messages:
The information in each RADIUS message is encapsulated in a UDP (User Datagram Protocol) data packet. A packet is a block of data in a standard format for transmission. It is accompanied by other information, such as the origin and destination of the data.
Table 1-1 lists each message packet which contains the following five fields:
| Fields | Description |
|---|---|
Indicates what type of message it is: Access-Request, Access-Accept, Access-Reject, Access-Challenge, Accounting-Request, or Accounting-Response. | |
Identifier | Contains a value that is copied into the server's response so the client can correctly associate its requests and the server's responses when multiple users are being authenticated. |
Length | Provides a simple error-checking device. The server silently drops a packet if it is shorter than the value specified in the length field, and ignores the octets beyond the value of the length field. |
Authenticator | Contains a value for a Request Authenticator or a Response Authenticator. The Request Authenticator is included in a client's Access-Request. The value is unpredictable and unique, and is added to the client/server shared secret so the combination can be run through a one-way algorithm. Cisco Access Registrar then uses the result in conjunction with the shared secret to encrypt the user's password. |
Attribute(s) | Depends on the type of message being sent. The number of attribute/value pairs included in the packet's attribute field is variable, including those required or optional for the type of service requested. |
The Attribute dictionary contains a list of preconfigured authentication, authorization, and accounting attributes that can be part of a client's or user's configuration. The dictionary entries translate an attribute into a value Cisco Access Registrar uses to parse incoming requests and generate responses. Attributes have a human-readable name and an enumerated equivalent from 1-255.
Sixty three standard attributes exist, which are defined in RFC 2138 and 2139. There also are additional vendor-specific attributes that depend on the particular NAS you are using. For a complete list of attributes, see "RADIUS Attributes."
Some sample attributes include:
Any one or all of the RADIUS server's three functions: authentication, authorization, or accounting can be subcontracted to another RADIUS server. Cisco Access Registrar then becomes a proxy server. Proxying to other servers enables you to delegate some of the RADIUS server's functions to other servers.
You could use Cisco Access Registrar to "proxy" to an LDAP server for access to directory information about users in order to authenticate them. Figure 1-2 shows user joe initiating a request, the Cisco Access Registrar server proxying the authentication to the LDAP server, and then performing the authorization and accounting processing in order to enable joe to log in.
Posted: Thu Aug 19 08:12:32 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.