Table of Contents

Radius
UserLists

Users

UserGroups
Clients
Vendors
Scripts
Services

Types of Services

local
radius, ldap, or tacacs-udp
file
rex

Session Managers

Session Creation
Session Notes

Resource Managers

Types of Resource Managers

IP-Dynamic
IP-Per-NAS-Port
IPX-Dynamic
Group-Session-Limit
User-Session-Limit
USR-VPN

Profiles
Remote Servers

Types of Protocols

radius
ldap
tacacs-udp

Advanced

Using the RequireNASsBehindProxyBeInClientList Property
Advance Duplicate Detection Feature

Ports
Interfaces
Reply Messages
Attribute Dictionary

Types
Vendor Attributes

Server Objects

This chapter describes the Cisco Access Registrar objects you use to configure and operate your 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.

• 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

• Session Managers---contains individual Session Managers

• Resource Managers---contains individual Resource Managers

• Profiles---contains individual Profiles

• RemoteServers---contains individual RemoteServers

• Advanced---contains advanced properties, Ports, Interfaces, Reply Messages, and the Attribute dictionary.

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.

The Radius properties are listed in Table 3-1, which you can set or change with the Cisco Access Registrar aregcmd commands.

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.

Table 3-2 lists the UserLists object properties.

Users

The Users object contains all of the information necessary to authenticate and/or authorize a user.

Table 3-3 lists the Users object properties.

Table 3-3: Users Properties

Property	Description
Name	Required. Must be unique in the specific UserList.
Description	Optional description of the user.
Password	Required. The length must be between 0-253.
Enabled	Required. The default is TRUE, which means the user is allowed access. Set to FALSE to cause Cisco Access Registrar to deny the user access.
Group	Optional. When you set this to the name of a UserGroup, Cisco Access Registrar uses the properties specified in that UserGroup to authenticate and/or authorize the user.
BaseProfile	Optional. When you set this to the name of a Profile, Cisco Access Registrar adds the properties in the Profile to the Response dictionary as part of the authorization.
AuthenticationScript	Optional. When you set this property to the name of a script, you can use the script to perform additional authentication checks to determine whether to accept or reject the user.
AuthorizationScript	Optional. When you set this property to the name of a script, you can use the script to add, delete, or modify the attributes of the Response dictionary.
UserDefined1	Optional. You can use this property to store notational information, which you can then use to filter the UserList.

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.

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-5 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 "RADIUS Dictionary Attributes" section.

Table 3-6 lists the Vendor object 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.

• REX (RADIUS EXtension) scripts are written in C or C++, and thus are compiled functions that reside in shared libraries

• Tcl scripts are written in Tcl, and are interpreted functions defined in source files.

Table 3-7 lists the Script object 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.

Services

Cisco Access Registrar supports AAA Services (authentication, authorization, and/or accounting). In addition to the variety of built-in AAA services (specified in the Type property), Cisco Access Registrar also provides you with the ability to add new AAA services through custom shared libraries.

Table 3-8 lists the Services properties.

Note, OutagePolicy also applies to Accounting-Requests. If an Accounting-Request is directed to an unavailable Service, then the values in Table 3-9 apply.

Types of Services

The Service you specify determines what additional information you must supply. The following are the types with their required and optional fields.

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.

radius, ldap, or tacacs-udp

Specify one of the following Services when you want to use a particular remote server for:

• radius---authentication and/or authorization

• ldap---authentication and/or authorization

• tacacs-udp---authentication.

You must supply the information listed in Table 3-10.

file

You specify the file Service when you want Cisco Access Registrar's RADIUS Server to perform local accounting using a specific file.

You must supply the information listed in Table 3-11.

rex

Specify the rex service type when you want to create a custom service by using a script for authentication, authorization, and/or accounting.

You must supply the information listed in Table 3-12.

For more information about scripting, see "Using Extension Points." For more information about using the REX Attribute dictionary, see "Cisco Access Registrar 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-13 lists the Session Manager properties.

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 and the "release-sessions" section.

Session Creation

Cisco Access Registrar Sessions can be created by two types of RADIUS packets:

• Access-Requests

• Accounting-Requests with an Acct-Status-Type attribute with a value of Start.

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 The Script should create an Environment dictionary entry using the Session Note name as the entry name, and the Session Note text as the entry value. For example:

$environ put "Date" "Today is 12/15/98"
$environ put "Request IP Address" "1.2.3.4"
 

Step 2 The Script should create/set an Environment dictionary entry with the name Session-Notes with a value that contains the name of the entries created. For example:

$environ put "Session-Notes" "Date, Requested IP Address"
 

For a REX script:

Step 1 The Script should create an Environment dictionary entry using the Session Note name as the entry name, and the Session Note text as the entry value. For example:

pEnviron-->put(pEnviron, "Date", "Today is 12/15/98.");
pEnviron-->put(pEnviron, "Request IP Address", "1.2.3.4");
 

Step 2 The Script should create/set an Environment dictionary entry with the name Session-Notes with a value that contains the name of the first entry created. For example:

pEnviron-->put(pEnviron, "Session-Notes", "Date, Requested IP Address");

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.

Resource Managers

Resource Managers allow you to allocate dynamic resources to user sessions. The following lists the different types of Resource Managers.

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

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

Table 3-14 lists the 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 "Environment Dictionary," 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-15.

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

IPX-Dynamic

IPX-Dynamic allows you to dynamically manage a pool of IPX networks.

When you use this Resource Manager, supply the information listed in Table 3-17.

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

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

USR-VPN

USR-VPN allows you to set up a VPN (Virtual Private Network) using a US Robotics NAS.

If you use this Resource Manager, supply the information listed in Table 3-20.

Gateway Subobject

If you use this Resource Manager, supply the information listed in Table 3-21.

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.

Table 3-22 lists the Profile properties.

Attributes

Attributes are specific RADIUS components of requests and responses defined in the Request and Response Attribute dictionaries. For a complete list of the attributes, see "RADIUS Attributes."

Table 3-23 lists the Attribute 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-24 lists the 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-25.

ldap

ldap specifies an LDAP server.

When you specify the ldap protocol, supply the information listed in Table 3-26.

Table 3-26: ldap Properties

Property	Description
Timeout	Required. The default is 15. The timeout property indicates how many seconds the RADIUS server will wait for a response from the LDAP server. If the LDAP server does not respond during the timeout period, Cisco Access Registrar initiates the failover behavior as specified in the list of RemoteServers.
HostName	Required. The LDAP server's host name or IP address.
BindName	Optional. The distinguished name (dn) to use when establishing a connection between the LDAP and RADIUS servers.
BindPassword	Optional. The password associated with the BindName.
SearchPath	Required. The path that indicates where in the LDAP database to start the search for user information.
Filter	Required. This specifies the search filter Cisco Access Registrar uses when querying the LDAP server for user information. When you configure this property, use the notation "%s" to indicate where the user ID should be inserted. For example, a typical value for this property is "(uid=%s)," which means that when querying for information about user joe, use the filter uid=joe.
UserPasswordAttribute	Required. This specifies which LDAP field the RADIUS server should check for the user's password.
LimitOutstandingRequests	Required. The default is FALSE. Cisco Access Registrar uses this property in conjunction with the MaxOutstandingRequests property to tune the RADIUS server's use of the LDAP server. When you set this property to TRUE, the number of outstanding requests for this RemoteServer is limited to the value you specified in MaxOutstandingRequests. When the number of requests exceeds this number, Cisco Access Registrar queues the remaining requests, and sends them as soon as the number of outstanding requests drops to this number.
MaxOutstandingRequests	Required when you have set the LimitOutstandingRequests to TRUE. The number you specify, which must be greater than zero, determines the maximum number of outstanding requests allowed for this remote server.
MaxReferrals	Required. Must be a number equal to or greater than zero. This property indicates how many referrals are allowed when looking up user information. When you set this property to zero, no referrals are allowed. Cisco Access Registrar manages referrals by allowing the RADIUS server's administrator to indicate an LDAP "referral attribute," which may or may not appear in the user information returned from an LDAP query. When this information is returned from a query, Cisco Access Registrar assumes it is a referral and initiates another query based on the referral. Referrals can also contain referrals. Note, this is an LDAP v2 referral property.
ReferralAttribute	Required when you have specified a MaxReferrals value. This property specifies which LDAP attribute, returned from an LDAP search, to check for referral information. Note, this is an LDAP v2 referral property.
ReferralFilter	Required when you have specified a MaxReferral value. This is the filter Cisco Access Registrar uses when processing referrals. When checking referrals, the information Cisco Access Registrar finds in the referral itself is considered to be the search path and this property provides the filter. The syntax is the same as that of the Filter property. Note, this is an LDAP v2 referral property.
PasswordEncryptionStyle	The default is None. You can also specify crypt.
LDAPToRadiusMappings	A list of name/value pairs in which the name is the name of the ldap attribute to retrieve from the user record, and the value is the name of the RADIUS attribute to set to the value of the ldap attribute retrieved. For example, when the LDAPToRadiusMappings has the entry: FramedIPAddress = Framed-IP-Address, the RemoteServer retrieves the attribute from the ldap user entry for the specified user, uses the value returned, and sets the Response variable Framed-IP-Address to that value.
LDAPToEnvironmentMappings	A list of name/value pairs in which the name is the name of the ldap attribute to retrieve from the user record, and the value is the name of the Environment variable to set to the value of the ldap attribute retrieved. For example, when the LDAPToEnvironmentMappings has the entry: group = User-Group, the RemoteServer retrieves the attribute from the ldap user entry for the specified user, uses the value returned, and sets the Environment variable User-Group to that value.
UseSSL	A boolean field indicating whether you want Cisco Access Registrar to use SSL (Secure Socket Layer) when communicating with this RemoteServer. When you set it to TRUE, be sure to specify the CertificateDBPath field in the Advanced section, and be sure the port you specified for this RemoteServer is the SSL port used by the LDAP server.

tacacs-udp

tacacs-udp specifies a TACACS server.

When you specify the tacacs-udp protocol, supply the information listed in Table 3-27.

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.

Table 3-28 lists the Advanced properties.

Table 3-28: Advanced Properties

Property	Description
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 AccountRequest 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 AccountingRequests. The default value was determined to provide a reasonable compromise between the two alternatives.
SessionBackingStoreSynchronization Interval	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.
MaximumNumberOfScriptingEnginesPer Language	Required. The default is 1. This property governs how many Tcl interpreters Cisco Access Registrar creates for processing scripts. Do not change the default value.
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.
UDPTacacsPacketsPerBlock	Required. The default is 10. This property governs how many UDP TACACS packets are allocated when Cisco Access Registrar needs to allocate more packets. You should not need to modify this value.
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, or the "ServerCert.db" certificate database used by Netscape 2.x servers.
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.
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).
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.

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:

• Set the UseAdvancedDuplicateDetection property in the /Radius/Advanced section of the configuration to TRUE.

• Set the AdvancedDuplicateDetectionMemoryInterval in the /Radius/Advanced section to specify how long (in milliseconds) Cisco Access Registrar should remember a request.

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.

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-29 lists the Reply Message properties.

Table 3-29: Reply Message Properties

Property	Description
Default	Optional. When you set this property, Cisco Access Registrar sends this value when the property corresponding to the reject reason is not set.
UnknownUser	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever Cisco Access Registrar cannot find the user specified by User-Name.
UserNotEnabled	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever the user account is disabled.
UserPassword Invalid	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever the password in the Access-Request packet did not match the password in the database.
UnableToAcquireResource	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever one of the Resource Managers was unable to allocate the resource for this request.
ServiceUnavailable	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever a service the request needs (such as a RemoteServer) is unavailable.
InternalError	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever an internal error caused the request to be rejected.
MalformedRequest	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever a required attribute (such as User-Name) is missing from the request.
ConfigurationError	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever the request is rejected due to a configuration error. For example, if a script sets an environment variable to the name of an object such as Authentication-Service, and that object does not exist in the configuration, the reason reported is ConfigurationError.
IncomingScriptFailed	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever one of the IncomingScripts fails to execute.
OutgoingScriptFailed	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever one of the OutgoingScripts fails to execute.
IncomingScriptRejectedRequest	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever one of the IncomingScripts rejects the Access-Request.
OutgoingScriptRejectedRequest	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever one of the OutgoingScripts rejects the Access-Request.
TerminationAction	Optional. When you set this property, Cisco Access Registrar sends back this value in the Reply-Message attribute whenever Cisco Access Registrar processes the Access-Request as a Termination-Action and is being rejected as a safety precaution.

Attribute Dictionary

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

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 2138) as well as the attributes required to support the major NASs. For more information about the standard attributes, see "RADIUS Attributes."

Table 3-30 lists the Attribute dictionary properties.

Types

Types are required and must be one of the following listed in Table 3-31.

Vendor Attributes

Table 3-32 lists the Vendor properties.

Posted: Thu Aug 26 16:27:34 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.