Understanding Cisco Access Registrar
Available Languages
Table Of Contents
Understanding Cisco Access Registrar
Cisco Access Registrar Hierarchy
Session Management Using Resource Managers
Client or NAS Scripting Points
Authentication and/or Authorization Scripting Points
Failover by the NAS and Session Management
Cross Server Session and Resource Management
Session-Service Service Step and Radius-Session Service
Configuring a Front Line Cisco Access Registrar
Understanding Cisco Access Registrar
This chapter describes the Cisco Access Registrar object structure, and explains when Cisco AR references each of these objects during the processing of client requests.
Cisco AR lets you manipulate configuration objects, which define the properties or behavior of the RADIUS server. Cisco AR also lets you invoke custom scripts to affect the behavior of the RADIUS server.
To better understand the role each of these objects plays in the program, it is helpful to look at the steps Cisco AR performs from receipt of an Access-Request packet to the sending of an Access-Response packet.
Cisco Access Registrar Hierarchy
Cisco 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. Cisco 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 and Groups
Cisco Access Registrar lets you organize your user community through the configuration objects UserLists, users, and UserGroups.
•
•
•
For more information about UserLists and UserGroups, refer to Access Registrar Server Objects in the Cisco Access Registrar User's Guide.
Profiles
Cisco 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, refer to Access Registrar Server Objects in the Cisco Access Registrar User's Guide.
Scripts
Cisco Access Registrar allows you to create scripts you can execute at various points within the processing hierarchy.
•
•
For more information about Scripts, refer to Access Registrar Server Objects in the Cisco Access Registrar User's Guide.
Services
Cisco 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 have specified more than one authentication service, Cisco Access Registrar determines which one to use for a particular Access-Request by checking the following:
•
•
Cisco 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, refer to Access Registrar Server Objects in the Cisco Access Registrar User's Guide.
Session Management Using Resource Managers
Cisco Access Registrar lets you track user sessions and 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.
•
•
•
•
•
•
For more information about Session Managers, refer to Access Registrar Server Objects in the Cisco Access Registrar User's 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, Cisco Access Registrar lets you pose queries about sessions. For example, you can query Cisco Access Registrar about which session (and thus which NAS-Identifier, NAS-Port and/or User-Name) owns a particular resource, as well as query Cisco Access Registrar about how many resources are allocated or how many sessions are active.
Program Flow
When a NAS sends a request packet to Cisco Access Registrar with a name and password, Cisco Access Registrar performs the following actions. Note, Table 2-1 describes the flow without regard to scripting points.
Scripting Points
Cisco Access Registrar lets you invoke scripts you can use to affect the Request, Response, or Environment dictionaries.
Client or NAS Scripting Points
Table 2-2 shows the location of the scripting points within the section that determines whether to accept the request from the client or NAS. Note, the scripting points are indicated with the asterisk (*) symbol.
Authentication and/or Authorization Scripting Points
Table 2-3 shows the location of the scripting points within the section that determines whether to perform authentication and/or authorization.
Table 2-3 Authentication and Authorization Scripting Points
Session Management
The Session Management feature requires the client (NAS or proxy) to send all RADIUS accounting requests to the Cisco Access Registrar server performing session management. (The only exception is if the clients are USR/3Com Network Access Servers configured to use the USR/3Com RADIUS resource management feature.) This information is used to keep track of user sessions, and the resources allocated to those sessions.
When another accounting RADIUS server needs this accounting information, the Cisco Access Registrar server performing session management may proxy it to this second server.
Table 2-4 describes how Cisco Access Registrar handles session management.
Table 2-4 Session Management Processing
Failover by the NAS and Session Management
When a Network Access Server's primary RADIUS server is performing session management, and the NAS determines the server is not responding and begins sending requests to its secondary RADIUS server, the following occurs:
•
•
For example, the user-session-limit resource may reject new sessions because the primary server does not know some of the users using the resource logged out while the primary server was off-line. It may be necessary to release sessions manually using the aregcmd command release-session.
Note
Script Processing Hierarchy
For request packets, the script processing order is from the most general to the most specific. For response packets, the processing order is from the most specific to the most general.
Table 2-5, Table 2-6, and Table 2-7 show the overall processing order and flow:
(1-6) Incoming Scripts, (7-11) Authentication/Authorization Scripts, and (12-17) Outgoing Scripts.
Note
Table 2-5 Cisco Access Registrar Processing Hierarchy for Incoming Scripts
1)
Radius
2)
Vendor of the immediate client.
3)
Immediate client.
4)
Vendor of the specific NAS.
5)
Specific NAS
6)
Service
Table 2-6 Cisco Access Registrar Processing Hierarchy for Authentication/Authorization Scripts
7)
Group Authentication.
8)
User Authentication.
9)
Group Authorization.
10)
User Authorization.
11)
Session Management.
Table 2-7 Cisco Access Registrar Processing Hierarchy for Outgoing Scripts
12)
Service
13)
Specific NAS.
14)
Vendor of the specific NAS.
15)
Immediate client.
16)
Vendor of the immediate client.
17)
Radius
Cross Server Session and Resource Management
Prior to CAR 1.6, sessions and resources were managed locally, meaning that in a multi-AR server environment, resources such as IP addresses, user-based session limits, and group-based session limits were divided between all the CAR servers. It also meant that, to ensure accurate session tracking, all packets relating to one user session were required to go to the same CAR server.
Overview
Cisco Access Registrar 1.6 and above can manage sessions and resources across AAA server boundaries. A session can be created by an Access-Request sent to AR1, and it can be removed by an Accounting-Stop request sent to AR2, as shown in Figure 2-1. This enables accurate tracking of User and Group session L across multiple AAA servers, and IP addresses allocated to sessions are managed in one place.
Figure 2-1 Multiple CAR Servers
All resources that must be shared cross multiple front line CAR servers are configured in the Central Resource CAR server. Resources that are not shared can still be configured at each front line CAR server as done prior to the CAR 1.6 release.
When the front line CAR server receives the access-request, it does the regular AA processing. If the packet is not rejected and a Central Resource CAR server is also configured, the front line CAR server will proxy the packet1 to the configured Central Resource CAR. If the Central Resource CAR server returns the requested resources, the process continues to the local session management (if local session manager is configured) for allocating any local resources. If the Central Resource CAR server cannot allocate the requested resource, the packet is rejected.
When the Accounting-Stop packet arrives at the frontline CAR, it does the regular accounting processing. Then, if the front line CAR server is configured to use Central Resource CAR, a proxy packet will be sent to Central Resource CAR server for it to release all the allocated resources for this session. After that, any locally allocated resources are released by the local session manager.
Session-Service Service Step and Radius-Session Service
A new Service step has been added in the processing of Access-Request and Accounting packets. This is an additional step after the AA processing for Access packet or Accounting processing for Accounting packet, but before the local session management processing. The Session-Service should have a service type of Radius-Session.
An environment variable Session-Service is introduced to determine the Session-Service dynamically. You can use a script or the policy engine to set the Session-Service environment variable.
Configuring a Front Line Cisco Access Registrar
To use a Central Resource server, the DefaultSessionService property must be set or the Session-Service environment variable must be set through a script or the policy engine. The value in the Session-Service variable overrides the DefaultSessionService.
The configuration parameters for a Session-Service service type are the same as those for configuring a radius service type for proxy, except the service type is radius-session.
The configuration for a Session-Service Remote Server is the same as configuring a proxy server.
[ //localhost/Radius ]
Name = Radius
Description =
Version = 1.7R0
IncomingScript =
OutgoingScript =
DefaultAuthenticationService = local-users
DefaultAuthorizationService = local-users
DefaultAccountingService = local-file
DefaultSessionService = Remote-Session-Service
DefaultSessionManager = session-mgr-1
[ //localhost/Radius/Services ]
Remote-Session-Service/
Name = Remote-Session-Service
Description =
Type = radius-session
IncomingScript =
OutgoingScript =
OutagePolicy = RejectAll
OutageScript =
MultipleServersPolicy = Failover
RemoteServers/
1. central-server
[ //localhost/Radius/RemoteServers ]
central-server/
Name = central-server
Description =
Protocol = RADIUS
IPAddress = 209.165.200.224
Port = 1645
ReactivateTimerInterval = 300000
SharedSecret = secret
Vendor =
IncomingScript =
OutgoingScript =
MaxTries = 3
InitialTimeout = 2000
AccountingPort = 1646Configure Central AR
Resources at the Central Resource server are configured the same way as local resources are configured. These resources are local resources from the Central Resource server's point of view.
1 The proxy packet is actually a resource allocation request, not an Access Request.
Feedback