The chapter provides an overview of the RADIUS server, including connection steps, RADIUS message types, and using Cisco Prime Access Registrar (Prime Access Registrar) as a proxy server.
Prime Access Registrar is a 3GPP-compliant, 64-bit carrier-class RADIUS (Remote Authentication Dial-In User Service)/Diameter server that enables multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.
Prime Access Registrar handles the following tasks:
- Authentication—determines the identity of users and whether they can be allowed to access the network
- Authorization—determines the level of network services available to authenticated users after they are connected
- Accounting—keeps track of each user’s network activity
- Session and resource management—tracks user sessions and allocates dynamic resources
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.
Prime Access Registrar also allows you to manage the complex interconnections of the new network elements in order to:
- adequately manage the traffic
- perform appropriate load balancing for desired load distribution
- allow binding of different protocol interfaces corresponding to a subscriber/network element
Service providers transform their 3G and 4G wireless networks with complex services, tiered charging, converged billing, and more by introducing increasing numbers and types of Diameter-based network elements. LTE and IMS networks are the most likely to implement these new network elements—including Policy and Charging Rules Functions (PCRF), Home Subscriber Servers (HSS), Mobility Management Entities (MME), Online Charging Systems (OCS), and others. As a result, as the traffic levels grow, these wireless networks are becoming more difficult to manage and scale without the Prime Access Registrar infrastructure.
Prime Access Registrar allows GUI-based, CLI-based, and REST API-based configurations. For more details, see Chapter 2, “Using the Graphical User Interface”, “Using the aregcmd Commands” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide, and “REST API Framework” chapter of the Cisco Prime Access Registrar 7.3 Reference Guide.
Prime Access Registrar Hierarchy
Prime Access Registrar’s operation and configuration is based on a set of objects. These objects are arranged in a hierarchical structure much like the Windows 95 Registry or the UNIX directory structure. Prime Access Registrar’s objects can themselves contain subobjects, just as directories can contain subdirectories. These objects include the following:
- Radius— the root of the configuration hierarchy
- UserLists—contains individual UserLists which in turn contain users
- UserGroups—contains individual UserGroups
- Users—contains individual authentication or authorization details of a user
- Clients—contains individual Clients
- Vendors—contains individual Vendors
- Scripts—contains individual Scripts
- Policies—contains a set of rules applied to an Access-Request
- Services—contains individual Services
- CommandSets—contains commands and the action to perform during Terminal Access Controller Access-Control System Plus (TACACS+) command authorization
- DeviceAccessRules—contains conditions or expressions and the applicable command sets for TACACS+ command authorization
- FastRules—provides a mechanism to easily choose the right authentication, authorization, accounting, and query service(s), drop, reject, or break flows, choose session manager or other rules required for processing a packet
- SessionManagers—contains individual Session Managers
- ResourceManagers—contains individual Resource Managers
- Profiles—contains individual Profiles
- RemoteServers—contains individual RemoteServers
- Advanced—contains Ports, Interfaces, Reply Messages, and the Attribute dictionary
This section contains the following topics:
UserLists and Groups
Prime Access Registrar lets you organize your user community through the configuration objects UserLists, users, and UserGroups.
- Use UserLists to group users by organization, such as Company A and Company B. Each list contains the actual names of the users.
- Use Users to store information about particular users, such as name, password, group membership, base profile, and so on.
- Use UserGroups to group users by function, such as PPP, Telnet, or multiprotocol users. Groups allow you to maintain common authentication and authorization requirements in one place, and have them referenced by many users.
For more information about UserLists and UserGroups, see the “Configuring and Monitoring the RADIUS Server” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide.
Prime Access Registrar uses Profiles that allow you to group RADIUS attributes to be included in an Access-Accept packet. These attributes include values that are appropriate for a particular user class, such as PPP or Telnet user. The user’s base profile defines the user’s attributes, which are then added to the response as part of the authorization process.
Although you can use Group or Profile objects in a similar manner, choosing whether to use one rather than the other depends on your site. If you require some choice in determining how to authorize or authenticate a user session, then creating specific profiles, and specifying a group that uses a script to choose among the profiles is more flexible. In such a situation, you might create a default group and then write a script that selects the appropriate profile based on the specific request. The benefit to this technique is each user can have a single entry, and use the appropriate profile depending on the way they log in.
For more information about Profiles, see the “Configuring and Monitoring the RADIUS Server” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide.
Prime Access Registrar allows you to create scripts you can execute at various points within the processing hierarchy.
- Incoming scripts—enable you to read and set the attributes of the request packet, and set or change the Environment dictionary variables. You can use the environment variables to control subsequent processing, such as specifying the use of a particular authentication service.
- Outgoing scripts—enable you to modify attributes returned in the response packet.
For more information about Scripts, see the “Configuring and Monitoring the RADIUS Server” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide.
Prime Access Registrar uses Services to let you determine how authentication, authorization, and/or accounting are performed.
For example, to use Services for authentication:
- When you want the authentication to be performed by the Prime Access Registrar RADIUS server, you can specify the local service. In this, case you must specify a specific UserList.
- When you want the authentication performed by another server, which might run an independent application on the same or different host than your RADIUS server, you can specify either a radius, ldap, or tacacs-udp service. In this case, you must list these servers by name.
When you have specified more than one authentication service, Prime Access Registrar determines which one to use for a particular Access-Request by checking the following:
- When an incoming script has set the Environment dictionary variable Authentication-Service with the name of a Service, Prime Access Registrar uses that service.
- Otherwise, Prime Access Registrar uses the default authentication service. The default authentication service is a property of the Radius object.
Prime Access Registrar chooses the authentication service based on the variable Authentication-Service, or the default. The properties of that Service, specify many of the details of that authentication service, such as, the specific user list to use or the specific application (possibly remote) to use in the authentication process.
For more information about Services, see the “Configuring and Monitoring the RADIUS Server” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide.
Session Management Using Resource Managers
Prime Access Registrar lets you track user sessions, and/or allocate dynamic resources to users for the lifetime of their session. You can define one or more Session Managers, and have each one manage the sessions for a particular group or company.
Session Managers use Resource Managers, which in turn manage resources of a particular type as described below.
- IP-Dynamic—manages a pool of IP addresses and allows you to dynamically allocate IP addresses from that pool
- IP-Per-NAS-Port—allows you to associate ports to specific IP addresses, and thus ensure each NAS port always gets the same IP address
- IPX-Dynamic—manages a pool of IPX network addresses
- Subnet-Dynamic—manages a pool of subnet addresses
- Group-Session-Limit—manages concurrent sessions for a group of users; that is, it keeps track of how many sessions are active and denies new sessions after the configured limit has been reached
- User-Session-Limit—manages per-user concurrent sessions; that is, it keeps track of how many sessions each user has and denies the user a new session after the configured limit has been reached
- Home-Agent—manages a pool of on-demand IP addresses
- USR-VPN—manages Virtual Private Networks (VPNs) that use USR NAS Clients
- Home-Agent-IPv6—manages a pool of on-demand IPv6 addresses
- Remote-IP-Dynamic —manages a pool of IP addresses that allows you to dynamically allocate IP addresses from a pool of addresses. It internally works with a remote ODBC database.
- Remote-User-Session-Limit —manages per-user concurrent sessions; that is, it keeps track of how many sessions each user has and denies the user a new session after the configured limit has been reached. It internally works with a remote ODBC database.
- Remote-Group-Session-Limit —manages concurrent sessions for a group of users; that is, it keeps track of how many sessions are active and denies new sessions after the configured limit has been reached. It internally works with a remote ODBC database.
- Session Cache —allows you to define the RADIUS attributes to store in cache.
- Dynamic-DNS —manages the DNS server.
- Remote-Session-Cache —allows you to define the RADIUS attributes to store in cache. It should be used with session manager of type 'remote'.
- 3GPP—allows you to define the attribute for 3GPP authorization.
For more information about Session Managers, see the “Configuring and Monitoring the RADIUS Server” chapter of the Cisco Prime Access Registrar 7.3 Administrator Guide.
If necessary, you can create a complex relationship between the Session Managers and the Resource Managers.
When you need to share a resource among Session Managers, you can create multiple Session Managers that refer to the same Resource Manager. For example, if one pool of IP addresses is shared by two departments, but each department has a separate policy about how many users can be logged in concurrently, you might create two Session Managers and three Resource Managers. One dynamic IP Resource Manager that is referenced by both Session Managers, and two concurrent session Resource Managers, one for each Session Manager.
In addition, Prime Access Registrar lets you pose queries about sessions. For example, you can query Prime Access Registrar about which session (and thus which NAS-Identifier, NAS-Port and/or User-Name) owns a particular resource, as well as query Prime Access Registrar about how many resources are allocated or how many sessions are active.
Types of RADIUS Messages
The client/server packet exchange consists primarily of the following types of RADIUS messages:
- Access-Request—sent by the client (NAS) requesting access
- Access-Reject—sent by the RADIUS server rejecting access
- Access-Accept—sent by the RADIUS server allowing access
- Access-Challenge—sent by the RADIUS server requesting more information in order to allow access. The NAS, after communicating with the user, responds with another Access-Request.
When you use RADIUS accounting, the client and server can also exchange the following two types of messages:
- Accounting-Request—sent by the client (NAS) requesting accounting
- Accounting-Response—sent by the RADIUS server acknowledging accounting
This section contains the following topics:
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 a description of the five fields in each message packet.
Table 1-1 RADIUS Packet Fields
Indicates message type: Access-Request, Access-Accept, Access-Reject, Access-Challenge, Accounting-Request, or Accounting-Response.
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 simultaneously.
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.
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. The NAS then uses the result in conjunction with the shared secret to encrypt the user’s password.
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
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 Prime 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.
Some sample attributes include:
- User-Name—the name of the user
- User-Password—the user’s password
- NAS-IP-Address—the IP address of the NAS
- NAS-Port—the NAS port the user is dialed in to
- Framed Protocol—such as SLIP or PPP
- Framed-IP-Address—the IP address the client uses for the session
- Filter-ID—vendor-specific; identifies a set of filters configured in the NAS
- Callback-Number—the actual callback number.
For a complete list of Cisco Prime Access Registrar documentation, see the Cisco Prime Access Registrar 7.3 Documentation Overview.
Note We sometimes update the documentation after original publication. Therefore, you should also review the documentation on Cisco.com for any updates.