Table of Contents

Configuring Groups

Configuring Specific Groups

Creating and Setting Group Membership

Configuring a Default Group

Using a Script to Determine Service

Configuring Multiple UserLists

Configuring Separate UserLists

Creating Separate UserLists

Configuring Users

Populating UserLists

Configuring Services

Creating Separate Services

Creating the Script
Configuring the Script

Choosing the Scripting Point
Handling Multiple Scripts

Configuring a Remote Server for AA

Configuring the Remote Server

Creating a RemoteServer

Configuring Services

Creating Services

Configuring the RADIUS Server

Changing the Authentication and Authorization Defaults

Configuring Multiple Remote Servers
Configuring Two Remote Servers

Creating RemoteServers

Configuring Services

Creating the Services

Configuring the Script

Choosing the Scripting Point

Configuring Session Management

Configuring a Resource Manager

Creating a Resource Manager

Configuring a Session Manager

Creating a Session Manager

Enabling Session Management

Configuring Session Management

Customizing Your Site

After you have configured and tested a basic site, you can begin to make changes to better address your own sites's needs.

This chapter describes the following types of sites:

The examples in this chapter provide an introduction to many of the Cisco Access Registrar objects and their properties. For more detailed descriptions, see the Cisco Access Registrar User Guide.

Configuring Groups

The first change you might want to make is to create distinct groups based on the type of service, and divide your user community according to these groups.

You can use Cisco Access Registrar's UserGroups in two ways:

• You can create separate groups for each specific type of service. For example, you can have a group for PPP users and another for Telnet users.

• You can use a default group and, depending on how the user logs in, use a script to determine which service to provide.

The default Cisco Access Registrar installation provides examples of both types of groups.

Configuring Specific Groups

For users who always require the same type of service, you can create specific user groups, and then set the user's group membership to that group.

Table 3-1 provides an overview of the process. The following sections describe the process in more detail.

Table 3-1: Configuring UserGroups

Object	Action
UserGroups	Add a new UserGroup
UserLists	Set group membership

Creating and Setting Group Membership

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the UserGroups object.

--> cd /Radius/UserGroups

Step 3 Use the add command to create a user group, specifying the name and optional description, BaseProfile, AuthenticationScript, or AuthorizationScript. The following example shows how to add the SLIP-users group.

This example sets the BaseProfile to default-SLIP-users. When you set this property to the name of a profile, Cisco Access Registrar adds the properties in the profile to the response dictionary as part of the authorization process.

--> save

Configuring a Default Group

If you allow users to request different Services based on how they specify their username, you can use a script to determine the type of Service to provide. For example, the user joe can request either PPP or Telnet Service by either logging in as joe%PPP or joe%Telnet.

Table 3-2 provides an overview of the process. The following sections describe the process in more detail.

Table 3-2: Choosing Among UserGroups

Object	Action
UserGroups	Add a new UserGroup or use existing Default group.
	Set AuthorizationScript
Scripts	Add new Script.
UserLists	Set group membership.

Using a Script to Determine Service

The following instructions assume you have already created a UserGroup and you have written a script that performs this function. For some sample scripts, see "Cisco Access Registrar Scripts."

Step 1 Use the cd command to change to the UserGroup you want to associate with the script. The following example changes to the Default group.

--> cd /Radius/UserGroups/Default

Step 2 Use the set command to set the AuthorizationScript to the name of the script you want run. The following example sets the script to AuthorizeService:

Step 4 Use the add command to add the new script, specifying the name, description, language (in this case Rex which is short for RADIUS Extension), file name and an optional entry point. When you do not specify an entry point, Cisco Access Registrar uses the script's name.

--> save

Configuring Multiple UserLists

The basic site contains a single userlist, Default, and uses group membership to determine the type of Service to provide each user. When all users are in the same UserList, each username must be unique.

You can, however, group your user community by department or location, and use separate UserLists to distinguish amongst them. In this case, the users names must be unique only within each UserList. Thus, you can allow a user Jane in the North UserList as well as one in the South UserList.

When you have more than one UserList, you must have an incoming script that Cisco Access Registrar can run in response to requests. The script chooses the authentication and/or authorization Service, and the Service specifies the actual UserList (Figure 3-1).

Table 3-3 provides an overview of the process. The following sections describe the process in more detail.

Table 3-3: Configuring Separate UserLists

Object	Action
UserLists	Add new UserLists.
Users	Add users.
Services	Add new Services.
	Set service type (local).
Radius	Set Incoming Script.
Scripts	Add a new Script.

Configuring Separate UserLists

Divide your site along organizational or company lines, and create a UserList for each unit.

Creating Separate UserLists

Step 1 Run the aregcmd command.

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to UserLists.

--> cd /Radius/UserLists

Step 3 Use the add command to create a UserList, specifying the name and optional description. The following example specifies the name North and the description Users from the northern office.

--> add North "Users from the northern office"

Step 4 Repeat for the other UserLists you want to add.

Configuring Users

After you have created multiple UserLists, you must populate them with the appropriate users.

Populating UserLists

Step 1 Use the cd command to change to the UserList you have created.

--> cd /Radius/UserLists/North

Step 2 Use the add command to add a user. Using the sample users as models, configure the appropriate group membership. The following example adds user beth, with the optional description telemarketing, the password 123, Enabled set to TRUE, and group membership to PPP-users.

--> add beth telemarketing 123 TRUE PPP-users

Step 3 Repeat for the other users you want to add.

You can use the script, add-100-users, which is located in the /opt/AICar1/examples/cli directory to automatically add 100 users.

Configuring Services

You must create a corresponding Service for each UserList. For example, when you create four UserLists, one for each section of the country, you must create four Services.

Creating Separate Services

Step 1 Use the cd command to change to Services:

--> cd /Radius/Services

Step 2 Use the add command to create a Service, specifying the name and optional description. The following example specifies the name North-users and the description All users from the northern branch office:

--> add North-users "All users from the northern branch office"

Step 3 Use the cd command to change to North-users.

--> cd /Radius/Services/North-users

Step 4 Use the set command to set the type to local. Specify the name of the UserList you want Cisco Access Registrar to use. You can accept the default Outage Policy and MultipleServersPolicy or you can use the set command to change them. The following example sets the type to local and the UserList to North:

Creating the Script

You must write a script that looks at the username and chooses the Service to which to direct the request.

For example, you create four UserLists (North, South, East, and West), with the Service based on the origin of the user. When a user requests a Service, your script can strip off the origin in the request and use it to set the environment dictionary variables Authentication-Service and/or Authorization-Service to the name or names of the appropriate Service.

In this situation, when beth@North.QuickExample.com makes an Access-Request, the script will strip off the word North and use it to set the value of the environment variable Authentication-Service and/or Authorization-Service. Note, the script overrides any existing default authentication and/or authorization specifications.

Configuring the Script

When you have multiple UserLists, you need a script to determine which UserList to check when a user makes an Access-Request. When you want the script to apply to all users, irrespective of the NAS they are using, place the script at the Radius level. When, on the other hand, you want to run different scripts depending on the originating NAS, place the script at the Client level.

Choosing the Scripting Point

Step 1 Use the cd command to change to the appropriate level. The following example sets the script for all requests.

--> cd /Radius

Step 2 Use the set command to set the incoming script. The following example sets the script, ParseUserName:

--> set IncomingScript ParseUserName

Step 3 Use the cd command to change to Scripts.

--> cd /Radius/Scripts

Step 4 Use the add command to add the new script, specifying the name, description, language, file name and an optional entry point. If you do not specify an entry point, Cisco Access Registrar uses the script's name.

The following example specifies the name ParseUserName, the language Rex (which is RADIUS Extension), the file name LibParseUserName.so, and the entry point ParseUserName.

--> add ParseUserName "" Rex libParseUserName.so ParseUserName

Step 5 Use the save command to save your changes:

--> save

Handling Multiple Scripts

When the Radius or Client object already has an IncomingScript defined, as is the case with the default Client localhost, you must create a master script that calls each of the scripts you want invoked. You then must specify the name of the master script as the appropriate IncomingScript.

Step 1 Use the cd command to change to the appropriate level. The following example sets the script for all requests from the Client, localhost.

--> cd /Radius/Client/localhost

Step 2 Use the set command to set the incoming script. The following example sets the script, MasterScript.

--> set IncomingScript MasterScript

Step 3 Use the cd command to change to Scripts:

--> cd /Radius/Scripts

Step 4 Use the add command to add the new script, specifying the name, description, language, file name and an optional entry point. When you do not specify an entry point, Cisco Access Registrar uses the script's name.

The following example adds the name MasterScript, the language Rex, the file name LibMasterScript.so, and the entry point MasterScript.

--> add MasterScript ""Rex libMasterScript.so MasterScript

Step 5 Use the save command to save your changes.

--> save

Configuring a Remote Server for AA

All the sites described so far in this chapter have used Cisco Access Registrar's RADIUS server for authentication and authorization. You might want to delegate either one or both of those tasks to another server, such as an LDAP server or another RADIUS server.

You can specify one of the following services when you want to use a particular remote server:

• radius---authentication and/or authorization

• ldap---authentication and/or authorization

• tacacs-udp---authentication only.

Table 3-4 provides an overview of the process. The following sections describe the process in more detail.

Table 3-4: Configuring a Remote Server

Object	Action
RemoteServers	Add a new RemoteServer.
	Set the protocol (ldap).
	Set the properties.
Services	Add a new Service.
	Set the type (ldap).
	Set the RemoteServers property.
Radius	Set DefaultAuthentication.
	Set DefaultAuthorization.

Configuring the Remote Server

The RemoteServer object allows you to specify the properties of the remote server to which Services proxy requests. The remote servers you specify at this level are referenced by name from the RemoteServers list in the Services objects.

Creating a RemoteServer

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the RemoteServers level:

--> cd /Radius/RemoteServers

Step 3 Use the add command to add the remote server you will reference in the Services level. The following example adds the remote server's host name QuickExample.

--> add QuickExample

Step 4 Use the cd command to change to the QuickExample RemoteServers object level.

--> cd /Radius/RemoteServers/QuickExample

Step 5 Use the set command to specify the protocol ldap:

--> set protocol ldap

Step 6 Use the set command to specify the required LDAP properties.

Configuring Services

In order to use LDAP for authorization and/or authentication, you must configure a Services object.

Creating Services

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the Services level:

--> cd /Radius/Services

Step 3 Use the add command to add the appropriate LDAP service. The following example adds the remote-ldap service:

Step 5 Use the set command to set the type to ldap. You can accept the default Outage Policy and MultipleServersPolicy or you can use the set command to change them.

Step 7 Use the set command to set the server number and name. By giving each server a number you tell Cisco Access Registrar the order you want it to access each server. Cisco Access Registrar uses this order when implementing the MultipleServersPolicy of Failover or RoundRobin.

• When you set it to Failover, Cisco Access Registrar directs requests to the first server in the list until it determines the server is off-line. At that time, Cisco Access Registrar redirects all requests to the next server in the list until it finds a server that is online.

• When you set it to RoundRobin, Cisco Access Registrar directs each request to the next server in the RemoteServers list in order to share the resource load across all the servers listed in the RemoteServers list.

Configuring the RADIUS Server

In the default Cisco Access Registrar configuration, authentication and authorization are handled through the local-users Service object. This causes Cisco Access Registrar to match requesting users with the names in its own database. When you select LDAP as a remote server for authentication and authorization, Cisco Access Registrar looks to that server for user information.

To have Cisco Access Registrar perform authentication and authorization against information from the LDAP server, you must change the DefaultAuthenticationService and DefaultAuthorizationService at the Radius level.

Changing the Authentication and Authorization Defaults

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the Radius level:

--> cd /Radius

Step 3 Use the set command to change the DefaultAuthentication:

--> set DefaultAuthentication remote-ldap

Step 4 Use the set command to change the DefaultAuthorization:

--> set DefaultAuthorization remote-ldap

Step 5 Use the save command to save your changes:

Configuring Multiple Remote Servers

All of the sites described so far in this chapter have used a single server for authentication and authorization; either the local RADIUS server or a remote LDAP server.

You can configure multiple remote servers to use the same Service, or multiple remote servers to use different Services. Figure 3-2 shows how to use multiple servers for authentication and authorization, and how to employ a script to determine which one to use.

Table 3-5 provides an overview of the process. The following sections describe the process in more detail. Repeat for each RemoteServer you want to configure.

Table 3-5: Configuring Multiple Remote Servers

Object	Action
RemoteServers	Add a new RemoteServer.
	Set the protocol (radius).
	Set the shared secret.
Services	Add a new Service.
	Set the type (radius).
	Set the remote server name and number.
Scripts	Add a new Script.
Radius	Set the IncomingScript.

Configuring Two Remote Servers

Configure each remote server you want to use for authentication and authorization. The following example shows the North remote server.

Creating RemoteServers

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the RemoteServers level:

--> cd /Radius/RemoteServers

Step 3 Use the add command to add the remote server you specified in the Services level. The following example adds the North remote server:

--> add North

Step 4 Use the cd command to change to the North RemoteServers level:

--> cd /Radius/RemoteServers/North

Step 5 Use the set command to specify the protocol radius:

--> set protocol radius

Step 6 Use the set command to specify the SharedSecret 789:

--> set SharedSecret 789

Step 7 Repeat for the other remote servers.

Configuring Services

In order to use multiple remote servers for authorization and/or authentication you must configure the corresponding Services.

Creating the Services

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the Services level:

--> cd /Radius/Services

Step 3 Use the add command to add the appropriate Radius service. The following example adds the NorthUsers-radius object:

Step 6 Use the set command to set the remote server number and name. By giving each server a number, you tell Cisco Access Registrar the order you want it to access each server. Cisco Access Registrar uses this order when implementing the MultipleServersPolicy of Failover or RoundRobin.

Configuring the Script

When you have multiple RemoteServers, you need a script that determines the authentication and/or authorization Service, which in turn specifies the RemoteServer to check when a user makes an Access-Request. If you want the script to apply to all users, irrespective of the NAS they are using, place the script at the Radius level.

Choosing the Scripting Point

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the Scripts object:

--> cd /Radius/Scripts

Step 3 Use the add command to add the new script, specifying the name, description, language, file name and an optional entry point. If you do not specify an entry point, Cisco Access Registrar uses the script's name.

The following example specifies the name ParseRemoteServers, the language Rex, the file name libParseRemoteServers.so, and the entry point ParseRemoteServers:

--> add ParseRemoteServers "" RexlibParseRemoteServers.so ParseRemoteServers

Step 4 Use the cd command to change to the appropriate object level. The following example changes to the server level:

--> cd /Radius

Step 5 Use the set command to set the incoming script. The following example sets the script, ParseRemoteServers, at the server level:

--> set IncomingScript ParseRemoteServers

Step 6 Use the save command to save your changes:

Configuring Session Management

You can use session management to track user sessions, and/or allocate dynamic resources to users for the lifetime of their sessions. You can define one or more Session Managers, and have each one manage the sessions for a particular group or company.

Configuring a Resource Manager

Session Managers use Resource Managers, which in turn manage a pool of resources of a particular type. The Resource Managers have the following types:

• IP-Dynamic---manages a pool of IP address and allows you to dynamically allocate IP addresses from that pool of addresses

• IP-Per-NAS-Port---allows you to associate NAS ports to specific IP addresses, and thus ensure specific NAS ports always get 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---allows you to set up a Virtual Private Network (VPN) using a US Robotics NAS. (A Virtual Private Network is a way for companies to use the Internet to securely transport private data.)

Table 3-6 provides an overview of the process. The following sections describe the process in more detail.

Table 3-6: Configuring ResourceManagers

Object	Action
ResourceManagers	Add new ResourceManager
	Set type (Group-Session-Limit)
	Set value (100)
SessionManagers	Add new SessionManager
	Set ResourceManager
Radius	Set DefaultSessionManager

Creating a Resource Manager

You can use the default Resource Managers as models for any new Resource Managers you want to create. The following describes how to create a Resource Manager that limits the number of users to 100 or less at any one time.

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the ResourceManagers level:

--> cd /Radius/ResourceManagers

Step 3 Use the add command to add a new ResourceManager. The following example adds the ResourceManager rm-100:

--> add rm-100

Step 4 Use the cd command to change to the ResourceManager you have just created:

--> cd rm-100

Step 5 Use the set command to set the type:

--> set type Group-Session-Limit

Step 6 Use the set command to set the number of GroupSessionLimit to 100:

--> set GroupSessionLimit 100

Configuring a Session Manager

Now that you have created a Resource Manager, you must associate it with the appropriate Session Manager.

Creating a Session Manager

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the SessionManagers level:

--> cd /Radius/SessionManagers

Step 3 Use the add command to add a new SessionManager. The following example adds the SessionManager sm-1:

--> add sm-1

Step 4 Use the cd command to change to the SessionManager/ResourceManagers property:

--> cd sm-1/ResourceManagers

Step 5 Use the set command to specify the ResourceManagers you want tracked per user session. Specify a number and the name of the ResourceManager. Note, you can list the ResourceManager objects in any order.

--> set 1 rm-100

Enabling Session Management

Cisco Access Registrar, by default, comes configured with the sample SessionManagement session-mgr-1. You can modify it or change it to the new SessionManager you have created.

Configuring Session Management

Step 1 Run the aregcmd command:

> /opt/AICar1/usrbin/aregcmd

Step 2 Use the cd command to change to the Radius level:

--> cd /Radius

Step 3 Use the set command to set the DefaultSessionManager to the name you have just created:

--> set DefaultSessionManager sm-1

Step 4 Use the save command to save your changes:

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