Table Of Contents
Understanding Cisco HLR Proxy Server
Cisco Access Registrar Hierarchy
Session Management Using Resource Managers
Cisco CNS Access Registrar HLR Proxy Server Directory Structure
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 HLR Proxy Server
This chapter describes the Cisco Access Registrar object structure, and explains when Cisco Access Registrar references each of these objects during the processing of client requests.
The Cisco HLR Proxy Server lets you manipulate configuration objects, which define the properties or behavior of the RADIUS server. The Cisco HLR Proxy Server 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 the Cisco HLR Proxy Server performs from receipt of an Access-Request packet to the sending of an Access-Response packet.
Cisco Access Registrar Hierarchy
The Cisco HLR Proxy Server'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. The Cisco HLR Proxy Server'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 HLR Proxy Server 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 CNS Access Registrar HLR Proxy Server 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 Server Objects in the Cisco CNS Access Registrar HLR Proxy Server 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 CNS Access Registrar HLR Proxy Server 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.
•
•
•
•
•
•
For more information about Session Managers, refer to Access Registrar Server Objects in the Cisco CNS Access Registrar HLR Proxy Server 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 CNS Access Registrar HLR Proxy Server 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.
Cisco CNS Access Registrar HLR Proxy Server Directory Structure
The installation process populates the /opt/CSCOar directory with the subdirectories listed in Table 2-1.
Note
Program Flow
When a NAS sends a request packet to Cisco CNS Access Registrar HLR Proxy Server with a name and password, Cisco CNS Access Registrar HLR Proxy Server performs the following actions. Note, Table 2-2 describes the flow without regard to scripting points.
Scripting Points
Cisco CNS Access Registrar HLR Proxy Server lets you invoke scripts you can use to affect the Request, Response, or Environment dictionaries.
Client or NAS Scripting Points
Table 2-3 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-4 shows the location of the scripting points within the section that determines whether to perform authentication and/or authorization.
Table 2-4 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 HLR Proxy 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 HLR Proxy Server server performing session management may proxy it to this second server.
Table 2-5 describes how Cisco CNS Access Registrar HLR Proxy Server handles session management.
Table 2-5 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-6, Table 2-7, and Table 2-8 show the overall processing order and flow:
(1-6) Incoming Scripts, (7-11) Authentication/Authorization Scripts, and (12-17) Outgoing Scripts.
Note
Table 2-6 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-7 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-8 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
Cisco CNS Access Registrar HLR Proxy Server 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 Cisco ICE Servers
All resources that must be shared cross multiple front line Cisco AR servers are configured in the Central Resource Cisco AR server. Resources that are not shared can still be configured at each front line Cisco AR server as done prior to the Cisco AR 1.6 release.
When the front line Cisco HLR Proxy Server receives the access-request, it does the regular AA processing. If the packet is not rejected and a Central Resource Cisco AR server is also configured, the front line Cisco AR server will proxy the packet1 to the configured Central Resource Cisco AR. If the Central Resource Cisco AR 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 Cisco AR server cannot allocate the requested resource, the packet is rejected.
When the Accounting-Stop packet arrives at the frontline Cisco HLR Proxy Server, it does the regular accounting processing. Then, if the front line Cisco HLR Proxy Server is configured to use Central Resource Cisco HLR Proxy Server, a proxy packet will be sent to Central Resource Cisco HLR Proxy 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.
