Table of Contents

Cisco Access Registrar Hierarchy

UserLists and Groups
Profiles
Scripts
Services
Session Management Using Resource Managers

Program Flow

Scripting Points

Client or NAS Scripting Points
Authentication and/or Authorization Scripting Points

Session Management

Failover by the NAS and Session Management

Script Processing Hierarchy

Understanding Cisco Access Registrar

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.

Cisco Access Registrar lets you manipulate configuration objects, which define the properties or behavior of the RADIUS server. Cisco Access Registrar 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 Access Registrar 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.

• Radius--- the root of the configuration hierarchy

• UserLists---contains individual UserLists which in turn contain users

• UserGroups---contains individual UserGroups

• Clients---contains individual Clients

• Vendors---contains individual Vendors

• Scripts---contains individual Scripts

• Services---contains individual Services

• 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.

UserLists and Groups

Cisco 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 "UserLists" section and the "UserGroups" section.

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, see the "Profiles" section.

Scripts

Cisco 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 "Scripts" section and "Using Extension Points."

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 want the authentication to be performed by the Cisco 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 may 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, Cisco 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, Cisco Access Registrar uses that service.

• Otherwise, Cisco Access Registrar uses the default authentication service. The default authentication service is a property of the Radius object.

For more information about Services, see the "Services" section.

Session Management Using Resource Managers

Cisco 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

• 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 once 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 once the configured limit has been reached

• USR-VPN---manages Virtual Private Networks (VPNs) that use USR NAS Clients.

For more information about Session Managers, see the "Session Managers" section.

If necessary, you can create a complex relationship between the Session Managers and the Resource Managers.

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.

Table 2-1: From Access-Request to Access-Accept

Action	Explanation
Receives an Access-Request.	The Cisco Access Registrar RADIUS server receives an Access-Request packet from a NAS.
Determines whether to accept the request.	Is the client's IP address listed in /Radius/Clients/<Name>/<IPAddress>.
Performs authentication and/or authorization.	Directs the request to the appropriate service, which then performs authentication and/or authorization according to the type specified in /Radius/Services/<Name>/<Type>.
Performs session management.	Directs the request to the appropriate Session Manager.
Performs resource management for each Resource Manager in the SessionManager.	Directs the request to the appropriate resource manager listed in /Radius/SessionManagers/<Name>/<ResourceManagers>/<Name>, which then allocates or checks the resource according to the type listed in /Radius/<ResourceManagers>/<Name>/<Type>.
Sends an Access-Accept.	Creates and formats the response, and sends it back to the client (NAS).

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.

Table 2-2: Client or NAS Scripting Points

Action	Explanation
Receives an Access-Request.	The Cisco Access Registrar RADIUS server receives an Access-Request packet from a NAS.
Determines whether to accept the request.	The client's IP address listed in /Radius/Clients/<Name>/IPAddress.
*Executes the server's incoming script.	A script referred to in /Radius/IncomingScript.
*Executes the vendor's incoming script.	The vendor listed in /Radius/Clients/Name/Vendor, and is a script referred to in /Radius/Vendors/<Name>/IncomingScript.
*Executes the client's incoming script.	A script referred to in /Radius/Clients/<Name>/IncomingScript.
Determines whether to accept requests from this specific NAS.
	/Radius/Advanced/RequireNASsBehindProxyBeInClientList set to TRUE.
	The NAS's Identifier listed in /Radius/Clients/<Name>, or its NAS-IP-Address listed in /Radius/Clients/<Name>/IPAddress.
If the client's IP address listed in /Radius/Clients/<Name>/IPAddress is different:
*Executes the vendor's incoming script.	The vendor listed in /Radius/Clients/Name/Vendor, and is a script referred to in /Radius/Vendors/<Name>/IncomingScript.
*Executes the client's incoming script.	The client listed in the previous /Radius/Clients/Name, and is a script referred to in /Radius/Clients/Name/IncomingScript.

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.

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.

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:

• The secondary server will not know about the current active sessions that are maintained on the primary server. Any resources managed by the secondary server must be distinct from those managed by the primary server, otherwise it will be possible to have two sessions with the same resources (for example, two sessions with the same IP address).

• The primary server will miss important information that allows it to maintain a correct model of what sessions are currently active (because the authentication and accounting requests are being sent to the secondary server). This means when the primary server comes back online and the NAS begins using it, its knowledge of what sessions are active will be out-of-date and the resources for those sessions are allocated even if they are free to allocate to someone else.

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.

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.

Posted: Thu Aug 19 08:13:14 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.