-
Cisco CNS Access Registrar User's Guide, 3.0
-
Index
-
About This Guide
-
Overview
-
Using aregcmd Commands
-
Access Registrar Server Objects
-
Using the radclient Commands
-
Configuring Local Authentication and Authorization
-
Using Extension Points
-
Using Replication
-
Using On-Demand Address Pools
-
Cisco Access Registrar Features
-
Using the Policy Engine
-
Wireless Support
-
Using LDAP
-
Using Open Database Connectivity
-
Backing Up the Database
-
Using the REX Accounting Script
-
Logging syslog Features
-
Troubleshooting Cisco Access Registrar
-
Cisco Access Registrar Dictionaries
-
Cisco Access Registrar Environment Variables
-
RADIUS Attributes
-
Cisco Access Registrar 3.0 User's Guide
-
Table Of Contents
Access Registrar Server Objects
Session Correlation Based on User-Defined Attributes
Using the RequireNASsBehindProxyBeInClientList Property
Advance Duplicate Detection Feature
Access Registrar Server Objects
This chapter describes the objects you use to configure and operate your Cisco Access Registrar RADIUS server.
Cisco Access Registrar is configured and operated through a set of objects. These objects are arranged in a hierarchy, with some of the objects containing subobjects; just as in a UNIX file system, in which directories can contain subdirectories. All of the objects, except those that are merely lists, contain properties that define the attributes or behavior of the object.
This chapter describes the Cisco Access Registrar objects:
•
Radius— root of the configuration hierarchy
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Radius
The Radius object is the root of the hierarchy. For each installation of the Cisco Access Registrar server, there is one instance of the Radius object. You reach all other objects in the hierarchy from the Radius.
Following is a listing of the RADIUS server object:
[ //localhost/Radius ]Name = RadiusDescription =Version = 1.7R0IncomingScript~ =OutgoingScript~ =DefaultAuthenticationService~ = local-usersDefaultAuthorizationService~ = local-usersDefaultAccountingService~ = local-fileDefaultSessionService~ =DefaultSessionManager~ = session-mgr-1UserLists/UserGroups/Policies/Clients/Vendors/Scripts/Services/SessionManagers/ResourceManagers/Profiles/Rules/Translations/TranslationGroups/RemoteServers/Advanced/Replication/Table 3-1 lists the Radius properties. You you can set or change Radius properties using the Cisco Access Registrar aregcmd commands.
Note
.
The remaining Cisco Access Registrar objects are subobjects of the Radius object.
UserLists
The UserLists object contains all of the individual UserLists, which in turn, contain the specific users stored within Cisco Access Registrar. Cisco Access Registrar references each specific UserList by name from a Service whose type is set to local. When Cisco Access Registrar receives a request, it directs it to a Service. When the Service has its type property set to local, the Service looks up the user's entry in the specific UserList and authenticates and/or authorizes the user against that entry.
Note
You can have more than one UserList in the UserLists object. Therefore, use the UserLists object to divide your user community by organization. For example, you might have separate UserLists objects for Company A and B, or you might have separate UserLists objects for different departments within a company.
Using separate UserLists objects allows you to have the same name in different lists. For example, if your company has three people named Bob and they work in different departments, you could create a UserList for each department, and each Bob could use his own name. Using UserLists lets you avoid the problem of Bob1, Bob2, and so on.
If you have more than one UserList, you can have a script Cisco Access Registrar can run in response to requests. The script chooses the Service, and the Service specifies the actual UserList which contains the user. The alternative is dynamic properties.
The subobjects are the Users listed by name. Table 3-2 lists the UserLists object properties.
Table 3-2 UserLists Properties
Name
Required. Must be unique in UserLists.
Description
Optional description of the UserList.
Users
The Users object contains all of the information necessary to authenticate a user or authorize a user. Users in local UserLists can have multiple profiles. Table 3-3 lists the Users object properties.
HiddenAttributes Property
In Cisco AR 3.0, a new property in the user object, HiddenAttributes, provides a concatenation of all user-level reply attributes. The Cisco AR 3.0 server uses the HiddenAttributes property to construct and populate a virtual attributes directory.
The HiddenAttributes property is, in fact, hidden. It is not displayed and cannot be set or modified using aregcmd, but when an administrator issues a save, all values from the user's Attributes directory go into the HiddenAttributes property and the persistent storage.
The attributes are added in a replace-if-present-add-if-not manner as used in the UserGroup-Base-Profile and User-Base-Profile. The order of application of the attributes is as follows:
•
•
•
•
UserGroups
The UserGroups objects allow you to maintain common authentication and authorization attributes in one location, and then have many users reference them. By having a central location for attributes, you can make modifications in one place instead of having to make individual changes throughout your user community.
For example, you can use several UserGroups to separate users by the services they use, such as a group specifying PPP and another for Telnet.
Table 3-4 lists the UserGroups properties.
Table 3-4 UserGroups Properties
Policies
A Policy is a set of rules applied to an Access-Request. If you are using Policies, the first one that must be created is SelectPolicy.
Table 3-5 lists the properties required for a given Policy.
Table 3-5 Policies Properties
Name
Required; must be unique in the Policies list
Description
Optional description of the Policy
Grouping
Optional grouping of rules
Clients
All NASs and proxy clients that communicate directly with Cisco Access Registrar must have an entry in the Clients list. This is required because NAS and proxy clients share a secret with the RADIUS server, which is used to encrypt passwords and to sign responses.
Table 3-6 lists the Client object properties.
Vendors
The Vendor object provides a central location for specifying all of the request and response processing a particular NAS or Proxy vendor requires. Depending on the vendor, it may be necessary to map attributes in the request from one set to another, or to filter out certain attributes before sending the response to the client. For more information about standard RADIUS attributes, see XREF - List of Attributes.
Note
Table 3-7 lists the Vendor object properties.
Table 3-7 Vendor Properties
Scripts
The Script objects define the function Cisco Access Registrar invokes whenever the Script is referenced by name from other objects in the configuration.
You can write two types of scripts:
•
•
Note
Table 3-8 lists the Script object properties.
Table 3-8 Script Properties
The InitEntryPoint properties allow you to perform initialization before processing and then cleanup before stopping the server. For example, when Cisco Access Registrar unloads the script (when it stops the RADIUS server) it calls the InitEntryPoint again to allow it to perform any clean-up operations as a result of its initialization. One use of the function might be to allow the script to close an open Accounting log file before stopping the RADIUS server.
Note
Services
Cisco Access Registrar supports authentication, authorization, and accounting (AAA) services. In addition to the variety of built-in AAA services (specified in the Type property), Cisco Access Registrar also enables you to add new AAA services through custom shared libraries.
Table 3-9 lists the Services properties.
Table 3-9 Services Properties
Note
Table 3-10 OutagePolicy Request Packets
Types of Services
This section lists the types of services available with their required and optional fields. The service you specify determines what additional information you must supply. The following are the types
local
Specify local when you want Cisco Access Registrar's RADIUS server to perform the authentication and/or authorization using a specific UserList. For more information, see the "UserLists" section.
EAP-LEAP
Cisco Access Registrar 3.0 supports the new AAA Cisco-proprietary protocol called Light Extensible Authentication Protocol (LEAP).
The Cisco AR server supports Extensible Authentication Protocol (EAP) to provide a common protocol for differing authentication mechanisms. EAP enables the dynamic selection of the authentication mechanism at authentication time based on information transmitted in the Access-Request. (This type of EAP authentication mechanism is called an authentication exchange.)
Note
The Cisco-Wireless or Lightweight Extensible Authentication Protocol (EAP-LEAP) is an EAP authentication mechanism where the user password is hashed based on an MD4 algorithm and verified by a challenge from both client and server.
Specify type eap-leap when you create an EAP-LEAP service. When you create an EAP-LEAP service type, you must also specify a UserService to perform AAA service. The UserService can be any configured authenticating service.
EAP-MD5
Cisco Access Registrar 3.0 supports EAP-MD5, or MD5-Challenge, another EAP authentication exchange. In EAP-MD5 there is a CHAP-like exchange, and the password is hashed by a challenge from both client and server to verify the password is correct. Once verified correct, the connection may proceed, although the connection is periodically re-challenged (per RFC 1994).
Specify type eap-md5 when you create an EAP-MD5 service. When you create an EAP-MD5 service type, you must also specify a UserService to perform AAA service. The UserService can be any configured authentication service.
radius, ldap, or tacacs-udp
Specify one of the following Services when you want to use a particular remote server for:
•
•
Note
•
Configure the properties listed in Table 3-11 to use a remote server and a RADIUS, LDAP or tacacs-upd service.
Table 3-11 radius, ldap, or tacacs-udp Properties
file
You specify the file Service when you want Cisco Access Registrar's RADIUS Server to perform local accounting using a specific file. Every file Service in your configuration will cause a file with the configured name to be created when the server is started, even if the service is not being invoked by any request packets.
When you specify a file Service, you must provide the information listed in Table 3-12.
Table 3-12 File Properties
Cisco Access Registrar opens the file when it starts the RADIUS server and closes the file when you stop the server. You can depend on Cisco AR flushes the accounting record to disk before it acknowledges the request.
Based on the maximum file size and age you have specified, Cisco AR closes the accounting file, moves it to a new name, and reopens the file as a new file. The name Cisco AR gives this accounting file depends on its creation and modification dates.
•
FileNamePrefix-<yyyymmdd>-<n>.log. The date is displayed as year, month, day, number.•
ODBC
To configure the ODBC Service, complete the following steps:
Step 1
[ /Radius/Services ]Entries 1 to 2 from 2 total entriesCurrent filter: <all>local-file/local-users/Step 2
--> add odbc
--> cd /Radius/Service/odbc-service
[ /Radius/Services/odbc-service ]Name = odbc-serviceDescription =Type = odbcIncomingScript~ =OutgoingScript~ =OutagePolicy~ = RejectAllOutageScript~ =MultipleServersPolicy = FailoverRemoteServers/Step 3
--> cd RemoteServers
[ /Radius/Services/odbc-service/RemoteServers ]--> add odbc
rex
Specify the rex service type when you want to create a custom service by using a script for authentication, authorization, or accounting.
You must supply the information listed in Table 3-13.
Table 3-13 rex Properties
For more information about scripting, see Chapter 5, "Using Extension Points." For more information about using the REX Attribute dictionary, see Appendix A, "Cisco Access Registrar Tcl and REX Dictionaries,".
Session Managers
You can use session management to track user sessions. The Session Managers monitor the flow of requests from each NAS and detect the session state. When requests come through to the Session Manager, it creates sessions, allocates resources from appropriate Resource Managers, and frees and deletes sessions when users log out.
The Session Manager enables you to 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 a pool of resources of a particular type.
Table 3-14 lists the Session Manager properties.
Table 3-14 Session Manager Properties
Name
Required. Must be unique in the Session Managers list.
Description
Optional. Description of the Session Manager.
Resource Managers
Ordered list of Resource Managers.
You can manage sessions with the two aregcmd session management commands: query-sessions and release-sessions. For more information about these two commands, see the "query-sessions" section on page 2-6 and the "release-sessions" section on page 2-6.
Session Creation
Cisco Access Registrar Sessions can be created by two types of RADIUS packets:
•
•
This allows Cisco Access Registrar to monitor Sessions even when it is not allocating resources. For example, when Cisco Access Registrar is being used as an "Accounting-Only" server (only receiving Accounting requests), it can create a Session for each Accounting "Start" packet it successfully processes. The corresponding Accounting "Stop" request will clean up the Session. Note, if a Session already exists for that NAS/NAS-Port/User (created by an Access-Request), Cisco Access Registrar will not create a new one.
When you do not want Cisco Access Registrar to create Sessions for Accounting "Start" requests, simply set the AllowAccountingStartToCreateSession property on the SessionManager to FALSE.
Session Notes
Session Notes are named text messages attached to a Session and are stored with the Session data, including resources allocated for a specific user session. This data, including Session Notes, can be retrieved and viewed using the aregcmd command query-sessions.
--> query-sessions /Radius/SessionManagers/session-mgr-2
sessions for /Radius/SessionManagers/session-mgr-2:
S257 NAS: localhost, NAS-Port:1, User-Name: user1, Time: 00:00:08,
IPX 0x1, GSL 1, USL 1, NOTES: "Date" "Today is 12/14/98.", "Requested
IP Address" "1.2.3.4", "Framed-IP-Address" "11.21.31.4"Session Notes can be created by Scripts using the Environment dictionary passed into each or by the Cisco Access Registrar server. When more than one Session Note is added, the Session-Notes entry should be a comma-separated list of entry names.
For a TCL script:
Step 1
$environ put "Date" "Today is 12/15/98"$environ put "Request IP Address" "1.2.3.4"Step 2
$environ put "Session-Notes" "Date, Requested_IP_Address"For a REX script:
Step 1
pEnviron-->put(pEnviron, Date, "Today is 12/15/98.");pEnviron-->put(pEnviron, Request_IP_Address, "1.2.3.4");Step 2
pEnviron-->put(pEnviron, "Session-Notes", "Date, Requested_IP_Address");
Note
Cisco Access Registrar will automatically create a Session Note if a packet is passed to a SessionManager and it already contains a Framed-IP-Address attribute in the packet's Response dictionary. This IP address could come from a Profile, RemoteServer response, or from a previously executed script. For example, a Session output containing Session Notes when using the aregcmd command query-session would be as follows:
sessions for /Radius/SessionManagers/session-mgr-2:S257 NAS: localhost, NAS-Port:1, User-Name: user1, Time: 00:00:08, IPX 0x1, GSL 1, USL 1, NOTES: "Date" "Today is 12/14/98.", "Requested IP Address" "1.2.3.4", "Framed-IP-Address" "11.21.31.4"Session Notes are also copied into the Environment dictionary after Session Management. The Session-Notes Environment dictionary entry will contain the names of all the Environment dictionary entries containing Session Notes.
Soft Group Session Limit
Two new environment variables, Group-Session-Limit and Current-Group-Count (see rex.h), are set if the group session limit resource is allocated for a packet. These variables allow a script to see how close the group is to its session limit; one way to use this information is to implement a script-based soft limit. For example, you could use the Class attribute to mark sessions that have exceeded a soft limit of 80% -- as hard coded in the script (in a Tcl script called from /Radius/OutgoingScript):
set softlimit [ expr 0.8 * [ $environ get Group-Session-Limit ] ]
if { [ $environ get Current-Group-Count ] < $softlimit } {
$response put Class 0
} else {
$response put Class 1
}
Note
Session Correlation Based on User-Defined Attributes
All the session objects are maintained in one dictionary keyed by a string. You can define the keying material to the session dictionary through a newly introduced environment variable, Session-Key.
If the Session-Key is presented at the time of session manager process, it will be used as the key to the session object for this session. The Session-Key is of type string. By default, the Session-Key is not set. Its value should come from attributes in the incoming packet and is typically set by scripts. For example, CLID can be used to set the value of Session-Key.
Use the function UseCLIDAsSessionKey as defined in the script rexscript.c to specify that the Calling-Station-Id attribute that should be used as the session key to correlate requests for the same session. This is a typical case for 3G mobile user session correlation. You can provide your own script to define other attributes as the session key.
In the absence of the Session-Key variable, the key to the session will be created based on the string concatenated by the value of the NAS-Identifier and the NAS-Port.
There is a new option with-key available in aregcmd for query-sessions and release-sessions to access sessions by Session-Key.
Resource Managers
Resource Managers allow you to allocate dynamic resources to user sessions. The following lists the different types of Resource Managers.
•
•
•
•
•
•
•
•
Each Resource Manager is responsible for examining the request and deciding whether to allocate a resource for the user, do nothing, or cause Cisco Access Registrar to reject the request.
Table 3-15 lists the Resource Manager properties.
Table 3-15 Resource Manager Properties
Types of Resource Managers
A number of different types of Resource Managers exist that allow you to manage IP addresses dynamically or statically, limit sessions on a per group or per user basis, or manage a Virtual Private Network. See Appendix A, "Cisco Access Registrar Tcl and REX Dictionaries" for information on how to override these individual Resource Managers.
IP-Dynamic
IP-Dynamic allows you to manage a pool of IP addresses from which you dynamically allocate IP addresses.
When you use this Resource Manager, supply the information listed in Table 3-16.
Table 3-16 IP-Dynamic Properties
NetMask
Required. Must be set to a valid net mask.
IPAddresses
Required. Must be a list of IP address ranges.
IP-Per-NAS-Port
IP-Per-NAS-Port allows you to associate specific IP addresses with specific NAS ports and thus ensures each NAS port always gets the same IP address.
When you use this Resource Manager, supply the information listed in Table 3-17.
Note
Table 3-17 IP-Per-NAS-Port Properties
IPX-Dynamic
An IPX-Dynamic Resource Manager allows you to dynamically manage a pool of IPX networks. When you use the IPX-Dynamic Resource Manager, supply the information listed in Table 3-18.
Table 3-18 IPX-Dynamic Property
Networks
Required. Must be a valid set of numbers which correspond to your networks.
Note
Subnet-Dynamic
A subnet-dynamic Resource Manager was created to support the On Demand Address Pool feature. Subnet-dynamic resource managers are used to provide pools of subnet addresses. Following is an example of the configuration of a subnet dynamic resource manager:
/Radius/ResourceManagers/newResourceMgrName = newResourceMgrDescription =Type = subnet-dynamicSubnet-Mask = 255.255.255.0SubnetAddresses/10.1.0.0-10.1.10.011.1.0.0-11.1.10.0When you use this Resource Manager, supply the information listed in Table 3-19.
Table 3-19 Subnet-Dynamic Properties
Type
Required
Subnet mask
Required; must be set to the size of the managed subnets
SubnetAddresses
Required; must be a valid range of IP addresses
Group-Session-Limit
Group-Session-Limit allows you to manage 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.
When you use this Resource Manager, supply the information listed in Table 3-20.
Table 3-20 Group-Session-Limit Property
GroupSessionLimit
Required. Must be set to the maximum number of concurrent sessions for all users.
User-Session-Limit
User-Session-Limit allows you to manage 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.
When you use this Resource Manager, supply the information listed in Table 3-21.
Table 3-21 User-Session-Limit Property
UserSessionLimit
Required. Must be set to the maximum number of concurrent sessions for a particular user.
Home-Agent
Home-Agent is a new resource manager that supports dynamic HA assignment. You configure the home-agent resource manager with a list of IP addresses. The AR server assigns those addresses to clients whose request dictionary has the right attributes to indicate that an assignment should be done. This is similar to the ip-dynamic resource manager.
Unlike the ip-dynamic resource manager, HAs are not exclusively allocated to an individual session but are shared among a set of sessions.
Detailed configuration information for the Home-Agent resource manager is found in Chapter 10, "Wireless Support". When you use this Resource Manager, supply the information listed in Table 3-22.
Table 3-22 Home-Agent Subdirectory
USR-VPN
USR-VPN allows you to set up a Virtual Private Network (VPN) using a US Robotics NAS.
When you use this Resource Manager, supply the information listed in Table 3-23.
Table 3-23 USR-VPN Properties
Gateway Subobject
The Gateway subobject includes a list of names of the Frame Relay Gateways for which to encrypt the session key.
If you use this Resource Manager, supply the information listed in Table 3-24.
Table 3-24 Gateway Properties
Profiles
You use Profiles to group RADIUS attributes that belong together, such as attributes that are appropriate for a particular class of PPP or Telnet user. You can reference profiles by name from either the UserGroup or the User properties. Thus, if the specifications of a particular profile change, you can make the change in a single place and have it propagated throughout your user community.
Although you can use UserGroups or Profiles in a similar manner, choosing whether to use one rather than the other depends on your site. When you require some choice in determining how to authorize or authenticate a user session, then creating specific profiles, and creating a group that uses a script to choose among them 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.
Table 3-25 lists the Profile properties.
Table 3-25 Profile Properties
Attributes
Attributes are specific RADIUS components of requests and responses defined in the Request and Response Attribute dictionaries. Use the aregcmd command set to assign values to attributes.
For a complete list of the attributes, see Appendix C, "RADIUS Attributes." Table 3-26 lists the Attribute properties.
Table 3-26 Attribute Properties
Name=value
The attribute name is one of the attributes defined in the Attribute dictionaries. The value is appropriate for the type of attribute.
When setting a value for a STRING-type attribute such as Connect-Info (which starts with an integer), you must use the hexadecimal representation of the integer. For example, to set the attribute Connect-Info to a value of 7:7, use a set command like the following:
set Connect-Info 37:3A:37
Translations
Translations add new attributes to a packet or change an existing attribute from one value to another. The Translations subdirectory lists all definitions of Translations the RADIUS server can apply to certain packets.
Under the /Radius/Translations directory, any translation to insert, substitute, or translate attributes can be added. The following is a sample configuration under the /Radius/Translations directory:
cd /Radius/Translations Add T1 cd T1 Set DeleAttrs Session-Timeout,Called-Station-Id cd Attributes Set Calling-Station-Id 18009998888DeleAttrs is the set of attributes to be deleted from the packet. Each attribute is comma separated and no spaces are allowed between attributes. All attribute value pairs under the attributes subdirectory are the attributes and values that are going to be added or translated to the packet.
Under the /Radius/Translations/T1/Attributes directory, inserted or translated attribute value pairs can be set. These attribute value pairs are either added to the packet or replaced with the new value.
If a translation applies to an Access-Request packet, by referencing the definition of that translation, the CAR server modifies the Request dictionary and inserts, filters and substitutes the attributes accordingly. You can set many translations for one packet and the CAR server applies these translations sequentially.
Note
Table 3-27 lists the Translation properties.
TranslationGroups
You can add translation groups for different user groups under TranslationGroups. All Translations under the Translations subdirectory are applied to those packets that fall into the groups. The groups are integrated with the CAR Rule engine.
The CAR Administrator can use any RADIUS attribute to determine the Translation Group. The incoming and outgoing translation group can be different translation groups. For example, you can set one translation group for incoming translations and one for outgoing translations.
Under the /Radius/TranslationGroups directory, translations can be grouped and applied to certain sets of packets, which are referred to in a rule. The following is a sample configuration under the /Radius/TranslationGroups directory:
cd /Radius/TranslationGroups Add CiscoIncoming cd CiscoIncoming cd Translations Set 1 T1The translation group is referenced through the Cisco Access Registrar Policy Engine in the /Radius/Rules/<RuleName>/Attributes directory. Incoming-Translation-Groups are set to a translation group (for example CiscoIncoming) and Outgoing-Translation-Groups to another translation group (for example CiscoOutgoing). Table 3-28 lists the Translation Group properties.
Remote Servers
You can use the RemoteServers object to specify the properties of the remote servers to which Services proxy requests. RemoteServers are referenced by name from the RemoteServers list in either the radius, ldap or tacacs-udp Services.
Table 3-29 lists the RemoteServers properties.
Table 3-29 RemoteServers Properties
Types of Protocols
The protocol you specify determines what additional information you must supply. The following are all of the protocols with their required and optional fields.
radius
radius specifies a RADIUS server.
When you specify the radius protocol, supply the information in Table 3-30.
ldap
ldap specifies an LDAP server. When you specify the ldap protocol, provide the information listed in Table 3-31.
For any LDAP remote service, the server might perform the environment mappings at any time. This means that if the service is set to either authentication and authorization, authentication-only, or authorization-only, environment mappings will take place. RADIUS mappings will take place only if the service is set to perform authorization. Checkitem mappings will take place only if the service is set to perform authentication. Previously environment mappings only occurred when the service was set for both authentication and authorization.
odbc
odbc specifies an ODBC server. Cisco Access Registrar provides a RemoteServer object (and a service) to support Open Database Connectivity (ODBC), an open specification that provides application developers a vendor-independent API with which to access data sources. Table 3-32 lists the odbc server attributes.
For any ODBC remote service, the server might perform the environment mappings at any time. This means that if the service is set to either authentication and authorization, authentication-only, or authorization-only, environment mappings will take place. RADIUS mappings will take place only if the service is set to perform authorization. Checkitem mappings will take place only if the service is set to perform authentication. Previously environment mappings only occurred when the service was set for both authentication and authorization.
tacacs-udp
tacacs-udp specifies a TACACS server. When you specify the tacacs-udp protocol, supply the information listed in Table 3-33.
Table 3-33 tacacs-udp Properties
Rules
A Rule is a function that selects services based on all input information used by the function.
Advanced
Advanced objects let you configure system-level properties and the Attribute dictionary. Under normal system operation, you should not need to change the system-level properties.
Note
Table 3-34 lists the Advanced properties.
Table 3-34 Advanced Object Properties
LogServerActivity
Required. The default is FALSE, which means Cisco Access Registrar logs all responses except Access-Accepts and Access-Challenges. Accepting the default reduces the load on the server by reducing that amount of information it must log. Note, the client is probably sending accounting requests to an accounting server, so the Access-Accept requests are being indirectly logged. When you set it to TRUE, Cisco Access Registrar logs all responses to the server log file.
MaximumNumberOfRadiusPackets
Required. The default is 1024. This is a critical property you should set high enough to allow for the maximum number of simultaneous requests. When more requests come in than there are packets allocated, Cisco Access Registrar will drop those additional requests.
UDPPacketSize
Required. The default is 4096. RFC 2138 specifies the maximum packet length can be 4096 bytes. Do not change this value.
RequireNASsBehindProxyBeInClientList
Required. The default is FALSE. If you accept the default, Cisco Access Registrar only uses the source IP address to identify the immediate client that sent the request. Leaving it FALSE is useful when this RADIUS Server should only know about the proxy server and should treat requests as if they came from the proxy server. This may be the case with some environments that buy bulk dial service from a third party and thus do not need to, or are unable to, list all of the NASs behind the third party's proxy server. When you set it to TRUE, you must list all of the NASs behind the Proxy in the Clients list. For more information about this property, see "Using the RequireNASsBehindProxyBeInClientList Property" section.
AAAFileServiceSyncInterval
Required. Specified in milliseconds, the default is 75. This property governs how often the file AAA service processes accounting requests and writes the accounting records to the file. You can lower the number to reduce the delay in acknowledging the Account-Request at the expense of more frequent flushing of the accounting file to disk. You can raise the number to reduce the cost of flushing to disk, at the expense of increasing the delays in acknowledging the Accounting-Requests. The default value was determined to provide a reasonable compromise between the two alternatives.
SessionBackingStoreSynchronizationInterval
Required. Specified in milliseconds, the default is 100. If you change this value it must be a number greater than zero. This property governs how often the Session Manager backing store writes updated session information to disk.
You can lower the number to reduce the delay in acknowledging requests at the expense of more frequent flushing of the file containing the session data to disk. You can raise the number to reduce the cost of flushing to disk at the expense of increasing delays in acknowledging requests. The default value was determined to provide a reasonable compromise between the two alternatives.
RemoteLDAPServiceThreadTimerInterval
Required. Specified in milliseconds, the default is 10. This property governs how often the ldap RemoteServer thread checks to see if any results have arrived from the remote LDAP server. You can modify it to improve the throughput of the server when it proxies requests to a remote LDAP server.
InitialBackgroundTimerSleepTime
Required. The default is 5. This property specifies the amount of time the time queue should initially sleep before beginning processing. This property is only used for initial synchronization and should not be changed.
MaximumNumberOfUDPTacacsPackets
Required. The default is 100. This is a critical property you should set high enough to allow for the maximum number of simultaneous proxied requests to the remote TACACS server. If more requests come in than there are packets allocated, Cisco Access Registrar will drop those additional requests.
MinimumSocketBufferSize
Required. The default is 65536 (64 K). This property governs how deep the system's buffer size is for queueing UDP datagrams until Cisco Access Registrar can read and process them. The default is probably sufficient for most sites. You can, however, raise or lower it as necessary.
CertificateDBPath
Required if you are using an LDAP RemoteServer, and you want Cisco Access Registrar to use SSL when communicating with that LDAP RemoteServer. This property specifies the name of the file containing the client certificates to be used when establishing an SSL connection to an LDAP RemoteServer. It must be either the cert5.db certificate database used by Netscape Navigator 3.x (and above), or the ServerCert.db certificate database used by Netscape 2.x servers.
LogFileSize
Required. The default is 1 Megabyte. This property specifies the maximum size of the RADIUS server log file. The value for the LogFileSize field is a string composed of two parts; a number, and a units indicator (<n> <units>) in which the unit is one of: K (Kilobyte, Kilobytes), M (Megabyte, Megabytes), G (Gigabyte, Gigabytes).
Note
LogFileCount
Required. The default is 2. This property specifies the number of log files to be kept on the system. A new log file is created when the log file size reaches LogFileSize.
UseAdvancedDuplicateDetection
Required. The default is FALSE. Set this property to TRUE when you want Cisco Access Registrar to use a more robust duplicate request filtering algorithm. For more information on this property, see the "Advance Duplicate Detection Feature" section.
AdvancedDuplicateDetectionMemoryInterval
Required when the Advanced Duplicate Detection feature is enabled. This property specifies how long (in milliseconds) Cisco Access Registrar should remember a request. You must specify a number greater than zero. The default is 10,000.
DefaultReturnedSubnetSizeIfNoMatch
Optional; used with the ODAP feature and reflects the returned size of the subnet if no matched subnet is found. There are three options to select if an exactly matched subnet does not exist: Bigger, Smaller, and Exact. The default is Bigger.
ClasspathForJavaExtensions
A String which is the classpath to be used to locate Java classes and jar files containing the classes required for loading the Java extensions - either Java extension points or services.
Note
JavaVMOptions
A String that can contain options that will be passed to the JRE upon startup. JavaVMOptions should be used only when requested by Cisco TAC.
MaximumODBCResultSize
Specifies maximum size in bytes for an ODBC mapping. This parameter affects both ODBC result sizes and the trace log buffer for tracing script calls that access any of the dictionaries. (Default value is 256.)
ARIsCaseInsensitive
When set to FALSE, requires that you provide exact path names with regard to upper and lower case for all objects, subobjects, and properties. The default setting, TRUE, allows you to enter paths such as /rad/serv instead of /Rad/Serv.
Note
RemoteRadiusServerInterface
When set, specifies the local interface to bind to when creating the RemoteRadiusServer socket. If not set, the Cisco AR binds to IPADDR_ANY.
Ports/
Optional; allows you to use ports other than the default, 1645 and 1646. You can use this option to configure Cisco Access Registrar to use other ports,. If you add additional ports, however, Access Registrar will use the added ports and no longer use ports 1645 and 1646. These ports can still be used by adding them to the list of ports to use. For more information, refer to "Ports" section.
Interfaces
Optional; refer to "Interfaces" section
ReplyMessages
Optional; refer to "Reply Messages" section.
AttributeDictionary
Optional; refer to "Attribute Dictionary" section.
SNMP
Optional; refer to "SNMP" section.
Using the RequireNASsBehindProxyBeInClientList Property
You can use the property RequireNASsBehindProxyBeInClientList to require NASs that send requests indirectly through a proxy to be listed in the Clients list or to allow the proxy to represent them all.
•
•
Advance Duplicate Detection Feature
Cisco Access Registrar automatically detects and handles duplicate requests it is currently working on. It also provides an optional, more complex mechanism to handle duplicate requests that may be received by the server after it has completed processing the original request. These duplicate requests can consume extra processing power, and, if received out of order (as RADIUS is a UDP-based protocol) may cause Session Management problems.
One solution is the Advanced Duplicate Detection feature which causes Cisco Access Registrar to remember requests it has seen, as well as the response sent to that request, for a configurable amount of time.
To enable this feature, perform the following:
•
•
Note
Ports
The Ports list specifies which ports to listen to for requests. When you specify a port, Cisco Access Registrar makes no distinction between the port used to receive Access-Requests and the port used to receive Accounting-Requests. Either request can come in on either port.
Most NASs send Access-Requests to port 1645 and Accounting-Requests to 1646, however, Cisco Access Registrar does not check.
When you do not specify any ports, Cisco Access Registrar does the following:
•
•
Interfaces
The Interfaces list specifies the interfaces on which the RADIUS server receives and sends requests. You specify an interface by its IP address.
•
•
Reply Messages
The Reply Messages list allows you to choose the reply message based on the reason the request was rejected. Each of the following properties (except Default) corresponds to a reason why the packet was rejected. The Reply Message properties allows you to substitute your own text string for the defined errors. After you set the property (with the set command) and the reason occurs, Cisco Access Registrar sends the NAS that message in the Access-Reject packet as a Reply-Message attribute.
You might want to substitute your own messages to prevent users from getting too much information about why their requests failed. For example, you might not want users to know the password was invalid to prevent hackers from accessing your system. In such a case, you might specify the text string "unauthorized access" for the property UserPasswordInvalid.
Table 3-35 lists the Reply Message properties.
Attribute Dictionary
The Attribute dictionary allows you to specify the attributes to the RADIUS server. Cisco Access Registrar comes with the standard RADIUS attributes (as defined by the RFC 2865) as well as the attributes required to support the major NASs. For more information about the standard attributes, see Appendix C, "RADIUS Attributes."
All RADIUS requests and responses consist of one or more attributes, such as the user's name, the user's password, the type of service the NAS should provide to the user, or the IP address the user should use for the session.
In the request and response packets, an attribute is composed of a number (between 1-255) that specifies the type of attribute to use, a length that specifies the entire attribute length, and a value. How the value is interpreted depends on its type. When it is a username, the value is a string. When it is the NAS's IP address, the value is an IP address, and so on.
Table 3-36 lists the Attribute dictionary properties.
Table 3-36 Attribute Dictionary Properties
Name
Required. Must be unique in the Attribute dictionary list within the same context. Although it should be an attribute defined in the RFC, the name can be any attribute defined by your client. The NAS typically comes with a list of attributes it uses.
Attributes are referenced in the Profile and by Scripts by this name. The accounting file service also uses this name when printing the attribute.
Description
Optional. Description of the attribute.
Attribute
Required. Must be a number between 1-255. It must be unique within the Attribute dictionary list.
Type
Required. Must be set to one of the types listed in Table 3-37. The type governs how the value is interpreted and printed.
Types
Types are required and must be one of the following listed in Table 3-37.
Table 3-37 Types Attributes
Vendor Attributes
Table 3-38 lists the Vendor properties.
SNMP
Table 3-39 lists the five properties of the SNMP directory.
If Enabled and MasterAgentEnabled are both TRUE, arservagt will start and stop the SNMP daemon (snmpd). If either of these properties is FALSE, if the AR server is not using SNMP or if your site uses a different master agent, arservagt will not start your master agent.
