|
|
This document contains important information about the 1.5 Cisco Access Registrar software. Cisco Access Registrar is a RADIUS (Remote Authentication Dial-In User Service) server that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.
This document is divided into the following sections:
The following documents are available on the Cisco Documentation CD-ROM and are companion documents to this document:
The following list of documents contains additional information which may help you more fully understand the material described in this manual:
This section describes the system requirements for installing the 1.5 Cisco Access Registrar software.
Table 1 lists the system requirements for a full installation of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6 or 2.7 |
Minimum RAM | 64 MB |
Recommended RAM | 128 MB |
Recommended Disk Space | 80 MB |
Table 2 lists the system requirements for installing the server-only component of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6 or 2.7 |
Minimum RAM | 64 MB |
Recommended RAM | 128 MB |
Recommended Disk Space | 60 MB |
Table 3 lists the system requirements for installing the configuration-only component of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6 or 2.7 |
Minimum RAM | 32 MB |
Recommended RAM | 64 MB |
Recommended Disk Space | 25 MB |
 | Caution The recommended disk space does not include the amount of space needed for accounting records which can grow rapidly depending on how frequently you process and remove them from the Cisco Access Registrar disk. If Cisco Access Registrar runs out of disk space, it could cause the loss of accounting information and session management information to become corrupted. |
If you are upgrading from a previous Cisco Access Registrar 1.2 or 1.3 release, you must do the following:
Step 1 Backup your Cisco Access Registrar 1.2 or 1.3 database. At the command line type:
mcdadmin -e <filename>
where <filename> is the name of the target file to export the database.
Step 2 Install the Cisco Access Registrar 1.5 product. Note, at minimum, you must install the 1.5 default database. You have the option of installing the 1.5 sample database.
Step 3 Import the Cisco Access Registrar 1.2 or 1.3 database file using the overwrite option in the mcdadmin command:
mcdadmin -o -i <filename>
where <filename> is the name of the file copied in Step 1. This command overwrites the Cisco Access Registrar 1.5 default database.
The 1.5 Cisco Access Registrar release includes the following new features:
1. "Single Master Database Replication Feature" section.
2. "Tunneling Support Feature" section.
3. "xDSL VPI/VCI Support for Cisco 6400" section.
4. "Apply Profile in Cisco Access Registrar Database to Directory Users" section.
5. "Directory Multi-Value Attributes Support" section.
6. "MultiLink-PPP(ML-PPP)" section.
7. "Dynamic Updates Feature" section.
8. "Rule Engine and Service Enhancements" section.
9. "aregcmd Command Logging" section.
The Single Master Database Replication (SMDBR) feature provides administrators with the ability to maintain databases on several different RADIUS servers without having to actually put into effect the changes on each server individually. In an SMDBR network, a single Master Server (upon which database changes are made) and one or more Member Servers (upon which database changes are made only through the Replication mechanism and not through aregcmd) exist. The database of a Member Server is maintained automatically by the Master Server. Changes are replicated throughout the network by the Master Server when an aregcmd save command is issued. With a few exceptions, all database changes are replicated to all network members and dynamically updated in each server such that a server reload is not required.
The following is a list of the configuration elements that are not replicated:
Replicated changes include additions or modifications. Deletions are not replicated (see the "Known Bugs" section for details).
All replications are based upon transactions. Should a transaction's replication fail, a resynchronism mechanism exists which will automatically resynchronize the database of a Replication Member with that of the Master. During resynchronization, the out-of-sync Member is set to off-line status and all Access Requests received are dropped while off-line (these requests are dropped so as to allow the NAS to redirect them to an on-line Member for processing). Once resynchronized, the Member automatically returns to an on-line status and Access Requests are processed as usual.
While on-line, all Members and the Master of a replication network perform as fully functional RADIUS Servers, regardless of the replication tasks being performed.
Install in the same manner as other RADIUS servers, however, you must set the Replication configuration parameters before the server will start correctly. See the "Master Configuration" section for details on how to configure the server for replication.
After installation is complete, run aregcmd and log into the newly installed server. Type cd radius/replication to change to the radius/replication directory. The following describes the replication configuration setup on a by-setting basis.
1. RepType <SMDBR>
This setting accepts the following values:
(a) SMDBR---specifies that this server is part of a Single Master replication network.
(b) LDAP---for future implementation. Setting this value has the same effect as using the NONE value.
(c) NONE---indicates this server is not part of a replication network.
2. RepTransactionSyncInterval = 60000
Specifies the time, in microseconds, between transmissions of a synchronization packet.
3. RepTransactionArchiveLimit = 100
Specifies the number of transactions to be archived. The choice of this value depends greatly on how many transactions are expected per unit time. When a Member determines that it is out-of-sync, the missing transactions needed by the Member are obtained from this archive. In this release, should a Member require one or more transactions which are beyond this limit, the Member will remain out-of-sync until a manual database resynchronization can be accomplished. Depending upon the number of anticipated aregcmd Save commands issued in a unit time, if this number is equal to that value, then a Member may not be Down for longer than that period of time. For example, if you expect your organization to issue 100 saves per day and the RepTransactionArchiveLimit attribute is set to 100, a Member may not be off-line for longer than a day without requiring a Full-Resynchronization (accomplished manually in this release). See the "Known Bugs" section for a description of the automatic Full-Resynchronization process.
4. RepIPAddress = <nnn.nnn.nnn.nnn>
Set this value to the IP address of this server.
5. RepPort = <nnn>
Set this value to the network port to use on this server.
6. RepSecret = MySecret
This is essentially the same as the shared secret used in other parts of the RADIUS configuration, however, this specific shared secret is shared between the Replication Network Members and its Master. Set this value to something to be used by the Replication Network only.
7. RepIsMaster = TRUE
This value must be set to TRUE.
8. RepMasterIPAddress = <nnn.nnn.nnn.nnn>
Set this value to the IP address of the Master. As the Master is being configured, set it to the IP address of this server (the same value as RepIPAddress).
9. RepMasterPort = <nnnn>
Set this value to the network port on the Master. As the Master is being configured, set it to the same value as the RepPort setting above.
Next, configure each Replication Network Member. For security reasons, this is only done on the Master.
10. Type cd rep to change to the Replication Members directory.
11. Type Add <name>, where <name> is the name of the Replication Network Member you are adding.
12. Type cd <name>, where <name> is the new replication network Member you just added.
13. Specify the IP address for the newly added Member by setting the IP address value to that of the Member server.
14. Specify the network port for the newly added Member by setting the Port value to that of the Member server.
15. Type cd ..
16. Repeat Steps 11 through 15 for each Replication Network Member.
17. Type Save to save your Replication Network Master setup.
Now that you have completed the setup of the Replication Network Master, you must configure each Replication Network Member such that it has the IP address and port of the Master (used to validate received replication data) and the replication secret specified on the Master.
After installation on the Member server is complete, run aregcmd and login to the newly installed Member server. Type cd radius/replication to change to the radius/replication directory. The following describes the replication configuration setup on a by-setting basis.
1. RepType = <SMDBR>
This setting accepts the following values:
(a) SMDBR---specifies that this server is part of a Single Master replication network.
(b) LDAP---for future implementation. Setting this value has the same effect as using the NONE value.
(c) NONE---indicates this server is not part of a Replication Network.
2. RepTransactionSyncInterval = 60000
Specifies the time, in microseconds, of the expected reception of a Synchronization packet. It is also used to determine if a transaction was completely received, to determine when communication with the Master may have failed, and as a general time-out when a reply is expected. This value may be significantly larger (but never lower) than that of the Master, as it may allow for long path transmissions which may be delayed for various reasons.
3. RepTransactionArchiveLimit = 100
Specifies the number of transactions which will be archived. On a member, this value need not be very large. A member's archive is only used to determine the most recently replicated transaction. It performs no other resynchronization tasks.
4. RepIPAddress = <nnn.nnn.nnn.nnn>
Set this value to the IP address of this server.
5. RepPort = < nnn>
Set this value to the network port to use on this server.
6. RepSecret = MySecret
This value must match the value specified in the RepSecret setting on the Master. If it does not match, replication will not occur for this Member.
7. RepIsMaster = FALSE
As a Member is being configured, this value must be FALSE. Only one Master may exist in any Replication Network.
8. RepMasterIPAddress = <nnn.nnn.nnn.nnn>
Set this value to the IP address of the Master.
9. RepMasterPort = <nnnn>
Set this value to the network port on the Master.
10. Type Save to save your Replication Network Member setup.
11. Repeat these steps on each server that is to be a Replication Network Member. Ensure that all Replication Network Members are defined in the Master, or they will be excluded from the Replication Network.
Start all the Replication Network Members and their Master. The order does not matter; however, if the RepTransactionSyncInterval on a Member expires prior to hearing from the Master, it will report in the server log that the Master may be off-line. Should this happen, and the master is in the process of starting, the member will eventually hear from the master and operation will continue as normal.
When a Replication Network Member starts-up, it is off-line until it can verify it is synchronized with the Master. If it is not synchronized, it will attempt a resynchronization, if it is possible, or the server will require manual resynchronization. When installing, you should ensure that if you are using an existing database, it is properly imported on each Member (from the Master) to ensure proper database synchronization from the start.
All configuration changes (except those which are not replicated) must be made to the Master server. While it is possible on a Replication Network Member to make changes to replicated configuration parameters, it is highly discouraged, as this practice will cause the database to be out-of-sync with the Master and other replication Members. This type of out-of-sync condition cannot be detected by the SMDBR network. Consequently, changes to the same configuration parameters made on the Master will overwrite any changes improperly made on the Member. aregcmd may be used to remotely login to the Master so that changes can always be made and replicated safely.
Changes to the non-replicated configuration parameters require a server reload for them to take effect. For example, if you wish to take a Member out of the Replication Network, set the RepType attribute to NONE, then reload the server. This will exclude the Member from the Replication Network. To put the server back into the Replication Network, set the RepType attribute to SMDBR, then reload it. When reinstating a Member, one of two things will occur:
1. If the Member missed less replication transactions than the RepTransactionArchiveLimit specification in the Master, an automatic resynchronization takes place and the Member will be on-line when it is resynchronized with the Master.
2. If the member missed more replication transactions than the RepTransactionArchiveLimit specification in the Master, a manual resynchronization must be done. To accomplish this, follow the steps under "No Full Synchronization" in the "Known Bugs" section below.
All replication configuration errors are logged in the configuration log and all replication errors and warnings pertaining to the SMDBR feature are logged in the server log.
1. Deletions Are Not Replicated.
Currently, the SMDBR cannot replicate deleted objects (that is, when a client is deleted on the Master, it is not deleted on the replication members). The workaround for this is to repeat the deletions on each Member.
2. No Full Resynchronization.
Full resynchronization is the process where the Master and an out-of-sync Member perform a database resynchronization on a parameter-by-parameter basis. This occurs when the last transaction received by a Member is no longer in the Master's Transaction Archive. A full resynchronization ensures that the Member has exactly the same replication parameters as the Master. This feature is not yet operational, so when this condition occurs, the only resolution is to export the Master's database and import the file on the Member. This requires some special treatment. The steps to accomplish this are as follows:
(a) Ensure there are no aregcmd sessions logged into the Master. On the Master, export the database with the following command:
mcdadmin -s -e <filename>
where <filename> is the name of the target file to export the database.
(b) Stop the replication Member server by invoking the arservagt stop command.
(c) Copy the file exported from the Master server to the Member server.
(d) Manually edit the file. Search for RepIsMaster, change its setting to FALSE, then save the file.
(e) Import the file using the overwrite option in the mcdadmin command:
mcdadmin -s -c -o -i <filename>
where <filename> is the name of the file copied in Step C and edited in Step D. This command overwrites the out-of-sync database with a copy from the Master.
(f) Start the replication Member by invoking the arservagt start command.
(g) Run aregcmd and set up the replication parameters as specified above in the "Member Configuration" section.
(h) Reload the server. The Member will start up and show on-line status in the log once it has verified it is synchronized with the Master.
Session Managers, Resource Managers, and Remote Servers may be added; however, any modifications are not dynamically updated in the server. This requires a reload. This is a preexisting artifact of the Dynamic Update implementation. It is important to note that while the Dynamic Update for these objects only supports additions, all additions and modifications are replicated to member's databases (they just are not dynamically updated in the member).
Tunneling support is strictly based upon the IETF draft: "RADIUS Attributes for Tunnel Protocol Support" (http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-09.txt).
Table 4 lists the tunneling attributes supported in this Cisco Access Registrar release.
| Attribute Number | Attribute |
|---|---|
64 | Tunnel-Type |
65 | Tunnel-Medium-Type |
66 | Tunnel-Client-Endpoint |
67 | Tunnel-Server-Endpoint |
69 | Tunnel-Password |
81 | Tunnel-Private-Group-ID |
82 | Tunnel-Assignment-ID |
83 | Tunnel-Preference |
90 | Tunnel-Client-Auth-ID |
91 | Tunnel-Server-Auth-ID |
The tunneling attribute has the following format:
(1 byte) | (1 byte) | (1 byte) | (variable number of bytes) |
Type | Length | Tag | Value |
1. Configure the tag attributes as untagged attributes under the /Radius/Advanced/Attribute Dictionary directory (for example, Tunnel-Type).
2. Attach the "_tag" tag to these attributes when configuring the attributes under all of the other directories as tagged attributes (for example, Tunnel-Type_tag10 under the /Radius/Profiles/test directory). Without the tag number, the default value is _tag0.
/Radius/Advanced/Attribute DictionaryMax = 253 /Radius/Profiles/test
/Tunnel-Client-ID
Name = Tunnel-Client-Endpoint
Description =
Attribute = 66
Type = STRING
Min = 0Name = test
Description =
/Attributes
Tunnel-Client-Endpoint_tag3 = "129.56.123.1"
1. "_tag" is reserved for the tunneling attributes. No other attributes should include it.
2. The tag number value can range from 0 through 31.
1. Cisco Access Registrar checks whether the tag attributes are defined under the /Radius/Advanced/Attribute Dictionary directory.
2. Cisco Access Registrar checks whether the tag number falls within the range (0-31).
To provide this support, a distinction must be made between device authentication packets and regular user authentication packets. To identify device authentication packets, the following changes are proposed for three scenarios.
This approach assumes that all Cisco 6400 devices are using the same User-Name and User-Password attributes for device authentication. The following changes must be made.
In the Cisco Access Registrar configuration, the 6400AAA script is defined as follows:
Name = 6400AAA Description = Language = REX Filename = libAR6400.so EntryPoint = Auth6400 InitEntryPoint = Init6400AAA InitEntryPointArgs = cisco::cisco
In the Cisco Access Registrar configuration, for each Network Access Server (NAS), a client incoming script is defined as follows:
Name = test6400-1 Description = IPAddress = 172.18.2.2 SharedSecret = secret Type = NAS Vendor = IncomingScript = 6400AAA OutgoingScript =
When the 6400 sends out the device authentication packet, Cisco Access Registrar assumes the User-Name/User-Password attributes are cisco/cisco (defined as the value of InitEntryPointArgs in the script definition). When Cisco Access Registrar verifies that the packet is from a known NAS, it runs the 6400AAA script. This all occurs prior to authentication taking place. The 6400AAA script does the device authentication work. First, it ensures the User-Name/User-Password attributes exist in the packet and that they match the cisco/cisco values configured as parameters in the 6400AAA script. When they do match, Cisco Access Registrar concludes that this is a 6400 device. The next step is to replace the User-Name attribute with the concatenated string of the <module>/<slot>/<port> etc. (see below). From this point, the packet is treated as a regular packet.
This approach assumes that for every 6400 NAS, a device-name/device-password is created for each. Following are the required changes:
For each NAS in Cisco Access Registrar:
Name = test6400-1 Description = IPAddress = 172.18.2.2 SharedSecret = secret Type = NAS Vendor = IncomingScript = OutgoingScript = Device-Name = theDevice Device-Password = thePassword
When the 6400 sends out the device authentication packet, it may have different User-Name/User-Password attributes for each 6400 NAS. When Cisco Access Registrar receives the packet, it tries to obtain the Device-Name/Device-Password attributes from the NAS entry in the Cisco Access Registrar configuration database. When the User-Name/User-Password in the packet match the configured Device-Name/Device-Password attribute values, Cisco Access Registrar assumes that it must get the device. The next step is to replace the User-Name attribute with the concatenated <module>/<slot>/<port> string. From this point, the packet is treated as a regular packet.
The individual User-Name/User-Password approach scales better; however, it requires more configuration on both the Cisco Access Registrar and NAS sides. The combined approach tries to use individual NAS User-Name/User-Password values; when defined. Otherwise, the global User-Name/User-Password values are used as default.
Following are the configuration steps. In the Cisco Access Registrar configuration, a script is defined:
6400AAAName = 6400AAA Description = Language = REX Filename = libAR6400.so EntryPoint = Auth6400 InitEntryPoint = Init6400AAA InitEntryPointArgs = cisco::cisco
Name = test6400-1 (device configured for individual User-Name/User-Password):
Description = IPAddress = 172.18.2.2 SharedSecret = secret Type = NAS Vendor = IncomingScript = OutgoingScript = Device-Name = theDevice Device-Password = thePassword
Name = test6400-2 (device configured for global User-Name/User-Password):
Description = IPAddress = 172.18.2.3 SharedSecret = secret Type = NAS Vendor = IncomingScript = 6400AAA OutgoingScript =
When Cisco Access Registrar gets a packet from a NAS, it first locates the NAS record. When it obtains Device-Name/Device-Password attributes, it uses them to identify the device. When the Device-Name/Device-Password attributes are not defined, and IncomingScript is defined, it uses the script to identify the device. When nothing is defined, it treats the packet as a regular packet and has it go through regular processing.
After the device is identified, the User-Name attribute is replaced with the new value. This new value is the concatenation of 6400 <module>/<slot>/<port> information and the packet is treated as a regular user authentication from this point on.
The format of the new User-Name attribute is the printf of "%s-%d-%d-%d-%d-%d" for the following values:
NAS-IP---in dot format of the NAS-Ip-Address attribute. For example, 10.10.10.10.
slot---apply mask 0xF0000000 on NAS-Port attribute and shift right 28 bits. For example, NAS-Port is 0x10000000, the slot value is 1.
module---apply mask 0x08000000 on NAS-Port attribute and shift right 27 bits. For example, NAS-Port is 0x08000000, the module value is 1.
port---apply mask 0x07000000 on NAS-Port attribute and shift right 24 bits. For example, NAS-Port is 0x06000000, the port value is 6.
VPI---apply mask 0x00FF0000 on NAS-Port attribute and shift right 16 bits. For example, NAS-Port is 0x00110000, the VPI value is 3.
VCI---apply mask 0x0000FFFF on NAS-Port attribute. For example, NAS-Port is 0x00001001, the VCI value is 9.
You can define the User-Profile and User-Group environment variables in the directory mapping and Cisco Access Registrar will apply the profiles defined in the Cisco Access Registrar database to each directory user having any of these two variables set.
This attribute is of type string with the format:
<Value1>::<Value2>
The User-Profile attribute is intended to hold a list of profile names. <Value1> and <Value2> represent the names of the profiles. They are separated by the "::" character, therefore, the "::" can not be part of the profile name. The order of values in the string has significance, as the profiles are evaluated from left to right. In this example, profile <Value2> is applied after profile <Value1>.
Assume the user record has a field called UserProfile that holds the name of the profile that applies to this user. This field is mapped to the environment attribute User-Profile. Following is how the mapping is done with aregcmd:
QuickExample/
Name = QuickExample
Description =
Protocol = ldap
IPAddress = 196.168.1.5
Port = 389
ReactivateTimerInterval = 300000
Timeout = 15
HostName = QuickExample.company.com
BindName =
BindPassword =
UseSSL = FALSE
SearchPath = "o=Ace Industry, c=US"
Filter = (uid=%s)
UserPasswordAttribute = password
LimitOutstandingRequests = FALSE
MaxOutstandingRequests = 0
MaxReferrals = 0
ReferralAttribute =
ReferralFilter =
PasswordEncryptionStyle = None
LDAPToEnvironmentMappings/
UserProfile = User-Profile
LDAPToRadiusMappings/
After Cisco Access Registrar authenticates the user, it checks whether User-Profile exists in the environment dictionary. If it finds User-Profile, for each value in User-Profile, Cisco Access Registrar looks up the profile object defined in the configuration database and adds all of the attributes in the profile object to the response dictionary. If any attribute is included in more than one profile, the newly applied profile overrides the attribute in the previous profile.
You can use the User-Group environment variable to apply the user profile as well. In Cisco Access Registrar, a user can belong to a user group, and that user group can have a pointer to a user profile. When Cisco Access Registrar finds that a packet has User-Group set, it obtains the value of the User-Profile within the user group, and if the User-Profile exists, it applies the attributes defined in the user profile to that user.
Note that in Cisco Access Registrar, every user can also directly have a pointer to a user profile. Cisco Access Registrar applies profiles is in the following order:
1. If the user profile defined in the user group exists, apply it.
2. If the user profile defined in the user record exists, apply it.
The profile in User-Group is more generic than in User-Profile. Therefore, Cisco Access Registrar applies the profile from generic to more specific.
You can use an existing user attribute in the user record to store profile info. When this is a new attribute, we suggest you create a new auxiliary class AR_UserRecord for whichever user class is used. AR_User_Profile and AR_User_Group are two optional members in this class. They are of type string. The mapping is as follows:
LDAPToEnvironmentMappings/ AR_User_Profile = User-Profile AR_User_Group = User-Group
If any attributes mapped from the LDAP directory to the Cisco Access Registrar response dictionary are multi-valued, the attributes are mapped to multiple RADIUS attributes in the packet.
Cisco Access Registrar supports MultiLink-PPP (ML-PPP). ML-PPP is an IETF standard, specified by RFC 1717. It describes a Layer 2 software implementation that opens multiple, simultaneous channels between systems, providing additional bandwidth-on-demand, for additional cost. The ML-PPP standard describes how to split, recombine, and sequence datagrams across multiple B channels to create a single logical connection. The multiple channels are the ports being used by the Network Access Server (NAS).
During the AA process, Cisco Access Registrar authenticates the user connection for each of its channels, even though they belong to the same logical connection. The Authentication process treats the multilink connection as if it is multiple, single link connections. For each connection, Cisco Access Registrar creates a session dedicated for management purposes. The session stays active until you logout, which subsequently frees up all of the ports in the NAS assigned to each individual session, or until the traffic is lower than a certain threshold so that the secondary B channels are destroyed thereafter. Cisco Access Registrar has the responsibility of maintaining the active session list and discards any session that is no longer valid in the system, by using the accounting stop packet issued from NAS. The multiple sessions that were established for a single logical connection must be destroyed upon the user logging out.
In addition, the accounting information that was gathered for the sessions must be aggregated for the corresponding logical connection by the accounting software. Cisco Access Registrar is only responsible for logging the accounting start and accounting stop times for each session. As those sessions belong to the same bundle, IETF provides two standard RADIUS attributes to identify the related multilink sessions. The attributes are Acct-Multi-Session-Id (attribute 50) and Acct-Link-Count (attribute 51), where Acct-Multi-Session-Id is a unique Accounting identifier used to link multiple related sessions in a log file, and Acct-Link-Count provides the number of links known to have existed in a given multilink session at the time the Accounting record was generated. The Accounting software is responsible for calculating the amount of the secondary B channel's connection time.
The secondary B channel can go up and down frequently, based upon traffic. The Ascend NAS supports the Target-Util attribute, which sets up the threshold for the secondary channel. When the traffic is above that threshold the secondary channel is up, and when the traffic is below that threshold, the secondary B channel is brought down by issuing an Accounting stop packet to Cisco Access Registrar. On the other hand, if you bring down the primary channel (that is, log out), the secondary B channel is also destroyed by issuing another Accounting stop packet to Cisco Access Registrar.
Table 5 lists ML-PPP related attributes.
| Number | Attribute | Cisco NAS (IOS 11.3 Release) | Ascend NAS |
|---|---|---|---|
44 | Acct-Session-Id | Supported | Supported |
50 | Acct-Multi-Session-Id | Supported | Supported |
51 | Acct-Link-Count | Supported | Supported |
62 | Port-Limit | Supported | Supported |
234 | Target-Util | Not Supported | Supported |
235 | Maximum-Channels | Supported | Supported |
Following are sample configurations for ML-PPP:
/Radius /Profile /Default-ISDN-Users Name = Default-ISDN-Users Description = Attributes/ Port-Limit = 2 Target-Util = 70 Session-Timeout = 70 /Radius /UserGroups /ISDN-Users Name = ISDN-Users Description = " Users who always use ISDN" BaseProfile = Default-ISDN-Users Authentication-Script = Authorization-Script =
The Port-Limit attribute controls the number of concurrent sessions a user can have. The Target-Util attribute controls the threshold level at which the second B channel should be brought up.
This feature allows changes to server configurations initiated from aregcmd to be effected in the Cisco Access Registrar server upon issuing the aregcmd save command. This alleviates the need for a server reload after changes are made. The following limitations exist:
1. Changes to the Ports or Interfaces objects are not dynamically updated. An aregcmd reload command must be issued for these changes to be propagated to the Cisco Access Registrar server.
2. Changes (modifications and deletions) to existing Session Manager and Resource Manager objects are not dynamically updated. An aregcmd reload command must be issued for these changes to be propagated to the Cisco Access Registrar server. However, additions of new Session Manager and Resource Manager objects are dynamically updated. Active sessions and allocated resources are preserved in this case.
3. Changes to the Cisco Access Registrar configuration may not be immediately propagated to the server. Dynamic updates are only carried out in a safe environment (that is, when packets are not being processed and when packet processing can be delayed until the changes can be made on the server safely). Dynamic updates will yield to packet processing when appropriate, thus not significantly impacting server performance.
The Cisco Access Registrar Rule Engine provides an interface to define and configure a policy and to apply the policy to the corresponding access-request packets. Authentication service is based on Realm, Dialed Number Information String (DNIS), and Calling Line ID (CLID). The following is an example set of policies and rules:
/Policies
/SelectPolicy
Name = SelectPolicy
Description =
Grouping = CiscoRealmRule|CiscoCLIDRule
/CiscoSelectPolicy
Name = CiscoSelectPolicy
Description =
Grouping = CiscoGroupRule
/CiscoDefaultPolicy
...
/CiscoExecPolicy
Name = CiscoExecPolicy
Description =
Grouping =CiscoExecTimeRule1&CiscoExecSecurityRule|CiscoExecTimeRule2
....
/Rules
/CiscoRealmRule
Name = CiscoRealmRule
Description =
Script = ExecRealmRule
/Attributes
Realm = @cisco.com
AuthenticationService = jen1-ultra
Policy = CiscoSelectPolicy
/CiscoCLIDRule
Name = CiscoCLIDRule
Description =
Script = ExecCLIDRule
/Attributes
...
/CiscoGroupRule
Name = CiscoGroupRule
Description =
Script = ExecGroupRule
/Attributes
Group = CiscoExec
Policy = CiscoExecPolicy
DefaultPolicy = CiscoDefaultPolicy
/CiscoExecTimeRule1
Name = CiscoExecTimeRule1
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "mon-fri,06:00-18:00";
AcceptedProfiles = PPP-USER
/CiscoExecTimeRule2
Name = CiscoExecTimeRule2
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "sun,18:00-24:00;sat,18:00-24:00";
AcceptedProfiles = TELNET-USER
/CiscoExecSecurityRule
Name = SecurityRule
Description =
Script = ExecSecurityRule
/Attributes
TunnelEnforcement = TRUE
AuthenticationProtocol = CHAP
1. /Radius/Policies/SelectPolicy is the first policy Cisco Access Registrar applies.
2. "|" and "&" are reserved as logical operands in a Grouping definition; they cannot be included in a /Radius/Rules name.
3. A space is not permitted between the logical operands and the rules in a Grouping definition.
4. The scripts included in the rules must be defined under the /Radius/Scripts directory.
5. The attributes included in the rules must be defined under the /Radius/Advanced/Attribute Dictionary directory.
6. The rules included in the policies must be defined under the /Radius/Rules directory.
When policies are configured, the following validations are performed by Cisco Access Registrar:
1. A check is performed to ensure the scripts included in the rules are defined under the /Radius/Scripts directory.
2. A check is performed to ensure the attributes included in the rules are defined under the /Radius/Advanced/Attribute Dictionary directory.
3. A check is performed to ensure the rules included in the policies are defined under the /Radius/Rule directory.
1. Grouping expressions are not checked for validity.
2. The use of parentheses to denote precedence is not supported in a Grouping definition.
3. A check is not performed to determine whether a policy that is included within another policy is defined under the /Radius/Policies directory.
The Cisco Access Registrar 1.5 release provides the following service enhancements:
1. Service determination by DNIS, Realm, or CLID, or a pattern match of these parameters.
2. Attributes Insertion/Substitution/Translation for proxy packets.
This requirement is for service determination by Realm, CLID, DNIS, and pattern matching to these three parameters for providing proxy or local services.
Service determination is set through the Cisco Access Registrar Rule Engine. To make all scripts ready to run, all scripts must be configured and set up through the aregcmd command. The following scripts are used for service determination:
These scripts extract the domain of the username or called-station-id or calling-station-id from the access request packet and compares it with the Realm, DNIS, or CLID set within the rule. Upon finding a match, the scripts will set the services (Authentication-Service, Authorization-Service, or Accounting-Service) into the Environment Dictionary.
In order to invoke this service enhancement, you must add rules and policies. Under the /Radius/Rules directory, you set the script that is going to be executed. Under the /Radius/Policies directory, you set the combination of rules.
Following is an example for adding a new Realm rule:
cd /Radius/Rules
Add RealmRule
cd RealmRule
Set Script ExecRealmRule
cd Attributes
Set Realm @cisco.com
SetAuthentication-Service local-users
SetAuthorization-Service local-users
where Realm is the domain filter for user name. If the user-name contains @cisco.com, the ExecRealmRule script sets Authentication-Service and Authorization-Service to local-users. The current release also supports the #cisco.com format.
Besides setting up the rules, you must also set up one or more policies. Policies can be any combination of rules using the and (&) and or (|) operators. Using the above example, a policy is setup as follows:
cd /Radius/Policies
Add SelectPolicy
cd SelectPolicy
Set Grouping RealmRule
This feature supports the RADIUS proxy with the ability to customize attribute filters so that RADIUS attribute value pairs can be inserted/deleted/substituted.
For example, when roaming a packet from ISP A to ISP B, some attribute value (AV) pairs may be substituted (such as IP address) as they may not be valid on B's network. Additionally, B may return some vendor-specific attributes (VSAs) that are not applicable to A's network. Therefore, A will substitute B's VSA value pairs for A's VSAs.
Two new configuration points have been added under the /Radius directory: Translations and TranslationGroups. Under the /Radius/Translations directory, any translation to insert/substitute/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 18009998888
DeleAttrs is the set of attributes to be deleted from the packet. Each attribute is comma separated and no spaces are allowed between attributes.
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.
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 T1
The translation group is referenced through the Cisco Access Registrar Rule 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).
The following is an example of setting up a rule for a translation group.
cd /Radius/Rules
Add CiscoTranslationRule
cd CiscoTranslationRule
cd Attributes
Set Realm @cisco.com
Set Incoming-Translation-Groups CiscoIncoming
Set Outgoing-Translation-Groups CiscoOutgoing
The CiscoTranslationRule rule must be referred to in the /Radius/Policies directory so the Cisco Access Registrar Rule Engine can invoke this rule. If the pattern of Realm, DNIS, or CLID matches the one defined in the rule, the Cisco Access Registrar Rule Engine sets Incoming-Translation-Groups to CiscoIncoming in the Environment Dictionary. By looking up the definition of CiscoIncoming, Cisco Access Registrar applies all of the translations to the incoming packet before it is proxied to the other server. When the proxied packet comes back to the RADIUS server, Cisco Access Registrar does a similar process to the outgoing packet. Note, Realm in the above example is a filter for packets whose user-name contains @cisco.com.
DNIS, CLID, and Realm are supported for filtering packets in the current release.
Cisco Access Registrar supports limited wildcard functionality. Cisco Access Registrar supports the "*" and "?" wildcard characters. "*" matches any number of characters, including the Null character, and "?" matches any single character, not including the Null character. Currently, wildcards apply to Realm, DNIS, and CLID attributes.
Realm=@cisco.com.
The following is an example using the "*" wildcard character:
/Radius /Rules /Rule1 Name=rule1 Description = ScriptName = ExecRealmRule Attributes/ Authentication-Service = Local-Users Authorization-Service = Local-Users Realm = @*cisco.com
In the above example, when the domain of the user name in an access request matches the @*cisco.com pattern (for example, @us.cisco.com, @eng.cisco.com, and @cisco.com are all good matches), the ExecRealmRule script sets Authentication-Service and Authorization-Service to Local-Users in the environment dictionary.
The following is an example using the "?" wildcard character:
/Radius
/Rules
/Rule2
Name = rule2
Description =
ScriptName = ExecDNISRule
Attributes/
Authentication-Service = Translation-Service
Authorization-Service = Translation-Service
DNIS = 1800345987?
In the above example, if the Called-Station-Id attribute in the packet matches 1800345987? (for example, 18003459876 and 18003459870 are good matches, while 1800345987 is not), the ExecDNISRule script sets Authentication-Service and Authorization-Service to Translation-Service in the environment dictionary.
Cisco Access Registrar also supports both wildcard characters in one pattern. For example,CLID = 180098?87* is valid.
The ExecTimeRule script, invoked by the Cisco Access Registrar Rule Engine, applies the TimeOfDay rule to the access request packet during the RADIUS server's incoming packet processing. The ExecTimeRule script either rejects or accepts the access request packets based upon the allowable user's login profiles within a certain time range.
The format of the TimeRange internal attribute is as follows:
TimeRange = dateRange, timeRange [; dateRange, TimeRange] dateRange = mdayRange | weekdayRange mdayRange = number [-number] number = 1 | 2 | 3 | | 31 weekdayRange = weekday [-weekday] weekday = sun | mon | tue | wed | thu | fri | sat timeRange = hh:mm - hh:mm hh = 00 | 01 | | 24 mm = 00 | 01 | | 60
For example:
mon-fri,09:00-17:00 mon,09:00-17:00; tue-sat,12:00-13:00 mon,09:00-24:00;tue,00:00-06:00 1-13,10-17:00; 15,00:00-24:00
The format of the AcceptedProfiles internal attribute is as follows:
AcceptedProfiles = userProfile[; userProfile]
The following is an example:
/Policies
...
/MarketingTODPolicy
Name = MarketingTODPolicy
Description =
Grouping = MarketingTODRule
/EngineeringTODPolicy
Name = EngineeringTODPolicy
Description =
Grouping = EngineeringTODRule
...
/Rules
...
/MarketingTODRule
Name = MarketingTODRule
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "mon-fri,8:00-17:00;sat,20:00-24:00;sun,00:00-7:00"
AcceptedProfile = PPP-users
/EngineeringTODRule
Name = EngineeringTODRule
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "sun-sat,00:00-24:00"
AcceptedProfiles = PPP-users;Telnet-users
...
1. Spaces cannot be used in the TimeRange or AcceptedProfiles attributes.
2. The lower limit must be less than the upper limit within any specified range.
Cisco Access Registrar validates the above configuration as follows:
1. Checks whether the ExecTimeRule script is defined under the /Radius/Scripts directory.
2. Checks whether the TimeRange and AcceptedProfiles attributes are defined under the /Radius/Advanced/Attributes Dictionary.
3. Checks whether the profiles included in the AcceptedProfiles attribute are defined under the /Radius/Profiles directory.
1. Cisco Access Registrar does not check the format of the TimeRange attribute.
2. Cisco Access Registrar does not validate the lower limit and the upper limit with the TimeRange attribute.
aregcmd now records the commands that are either entered interactively or executed in batch mode. The recorded commands are saved in the aregcmd_log file, which resides in the logs directory within the Cisco Access Registrar installation directory.
For security reasons, aregcmd blocks out the actual password that is entered as part of the command and replaces it with <passwd>.
In interactive mode, aregcmd logs the actions that are taking place in the exit/logout dialog box. The action can be save or not save if the configuration database has been modified after the last execution of the save command.
In non-interactive (batch) mode, aregcmd replaces the empty field with a NULL string.
aregcmd is now installed as a setgid program where the group is set to staff. This allows a non-root user to run aregcmd while still being able to write to the aregcmd_log log file. During the installation of the Cisco Access Registrar product, you are prompted whether you want to install aregcmd with setuid/setgid permissions. You must reply "yes" unless you only run aregcmd as user root.
The following is the format of an entry in the exit/logout dialog box when not save has been specified:
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( exit )
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( *** New config is not saved!
...proceed to logout.)
The following is sample output of an entry in the exit/logout dialog box when not save has been specified:
09/23/1999 16:18:56 aregcmd Info Configuration 0
[localhost admin] --> quit
09/23/1999 16:19:02 aregcmd Info Configuration 0
[localhost admin] --> *** New config is not saved!
...proceed to logout.
The following is the format of an entry in the exit/logout dialog box when save has been specified:
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( exit )
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( *** New config saved!
...proceed to logout.)
Commands entered at the aregcmd prompt can be edited with a subset of the standard EMACS style key strokes. A description of the supported key strokes are shown in Table 6.
| Key Stroke | Description |
|---|---|
Ctrl A | Go to the beginning of the line. |
Ctrl B | Move back one character. |
Ctrl D | Delete the character at the cursor. |
Ctrl E | Go to the end of the line. |
Ctrl F | Move forward one character. |
Ctrl N | Retrieve the next line. |
Ctrl P | Retrieve the previous line. |
RADIUS server up/down detection and logging has been added to this release of Cisco Access Registrar. The information messages are saved in the <AR_install_dir>/logs/name_radius_1_log file where <AR_install_dir> is Cisco Access Registrar installation directory.
Each message consists of a header and a message description.
The format of a header entry is:
mm/dd/yyyy HH:MM:SS name/radius/n Error Server 0
Following are the descriptions and types of messages that can be found within the <AR_install_dir>/logs/name_radius_1_log file.
1. Cisco Access Registrar detects a remote server when it responds for the first time or after it is reentered into Cisco Access Registrar's server pool for retry. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) is UP!
The following is an example header and message:
09/14/1999 17:56:32 name/radius/1 Error Server 0
Remote server dave-ultra (171.69.237.99:1645) is UP!
2. Cisco Access Registrar detects the remote server is not responding to its request. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) is DOWN!
The following is an example header and message:
09/14/1999 17:57:12 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is DOWN!
3. Cisco Access Registrar receives no response from the remote server after the server is reentered into Cisco Access Registrar's server pool for retry. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) remains DOWN!
The following is an example header and message:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) remains DOWN!
4. The remote server is responding to the first retry but not the initial request. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) is UP but slow!
The following is an example header and message:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is UP but slow!
5. The remote server is responding to the second retry request but not the initial request or the first retry request. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) is UP but very slow!
The following is an example header and message:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is UP but very slow!
6. The remote server has been marked inactive and is being put back into Cisco Access Registrar's server pool for later use. The format of the message is:
Remote server <hostname> (<ipaddress>:<port>) is being reactivated for later use.
The following is an example header and message:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is being reactivated for later use.
This section describes the bugs fixed in the 1.5 release of Cisco Access Registrar.
| Bug Number | Description |
|---|---|
CSCai03470 | Process ParseAARealm has regular expression bug. This was fixed in the destiny/servers/radius/src/tclscript.tcl file for the following processes:
|
CSCdm82121 | Multistream accounting script core dumps server. We have found that the Solaris localtime() call is not thread safe and so a change has been made to avoid using this function. |
CSCdp24841 | Added new aregcmd logging and RADIUS server up/down detection. |
This section describes the bugs known to exist in this release of Cisco Access Registrar.
| Bug Number | Description | ||||||
|---|---|---|---|---|---|---|---|
CSCdm49977 | aregcmd and radclient hang when /temp is full. The second instance will hang on login. CTRL-C will not work. Trying to use kill to remove the process will result in a PPID of 1 to one of the processes. The only way to remove the hung process is to reboot. The second instance does not need to be the same program as the first instance. Note You will not be able to shut down the RADIUS server due to the running process. | ||||||
CSCdm64258 | Cannot run more than six aregcmd sessions to one server. | ||||||
CSCdm92870 | Validate does not fail for an empty UserList in a service. If a new service is created without a UserList, it will pass validation and save, but reload will fail with the following error: The server wrote the following errors to the log file: Configuration Internal Error in /Radius/Services/<service name>/: Required property UserList did not exist. Validation should fail in this case. | ||||||
CSCdp21838 | ls -R inconsistent in certain objects. If the Resource Manager object is set to type ip-dynamic, running ls -R with more than twenty IP pools results in only the current twenty pools being listed. Other sets of twenty appear when you cd into the pools and do a previous/next before doing another ls -R. | ||||||
CSCdp21844 | Inconsistent directory reporting in aregcmd. When you cd into certain objects within aregcmd, the current directory is not updated properly. This behavior is seen in the IP pools for a Resource Manager set to type ip-dynamic. | ||||||
CSCdp23831 | Loss of authentication when log partition is full/not writable. It has been suggested in the past that this is a documented "feature" of Cisco Access Registrar. I was unable to find any documentation pointing this out. Additionally, in the kind of mission critical environments that Cisco Access Registrar is placed in, keeping the processing of authentication requests running is necessary regardless of whether (or not) the logs can still be written. | ||||||
CSCdp64341 | Validate does not fail after deleting a referenced remote server. | ||||||
CSCdp91695 | Misleading aregcmd error reported. In aregcmd, when cd /Radius/Translation is invoked, an error message stating the directory could not be found is erroneously displayed. Instead, an error message stating the path is ambiguous should be displayed, as the /Radius/Translation and /Radius/TranslationGroups directories do exist. | ||||||
CSCdp91733 | Example data sources do not match. The example data imported while installing Cisco Access Registrar does not match the example data when installed through the ad-example-configuration.rc script. | ||||||
CSCdp91753 | Logging does not work for files greater than or equal to 2Gb. No more logging occurs when the log file grows to over 2047Mb. | ||||||
CSCdp92780 | Upgrade configuration option needed. The install package should ask if the user would like help upgrading an existing database. If so, all the necessary configuration files should be added into the old configuration. At this point`, the Rule Engine and any translation scripts and attributes fall into this action. | ||||||
CSCdr05185 | No validation on the replication attributes. | ||||||
CSCdr05605 | Core generated after setting a rule without script and/or attribute. | ||||||
CSCdr05617 | When a tag attribute is created such as | ||||||
CSCdr06186 | Multiple rules did not get executed. After setting the policy=newPolicy rule, it was not executed. Only the selectpolicy rule was executed. Even though selectpolicy is the entry point, it should execute all policies if it is referenced in the policy. | ||||||
CSCdr09456 | Default RADIUS ports are not RFC compliant. Note, you can define multiple ports per your choosing. | ||||||
CSCdr13784 | arservagt does not check for root uid. The arservagt script tries to write to a file in $INSTALLPATH/logs which is owned by root. However, the script does not check for the root uid and emits a misleading error when the script is accidentally run by a non-root uid. | ||||||
CSCdr14054 | A policy cannot be referred to in a rule if it is not defined. | ||||||
CSCdr14061 | Cisco Access Registrar goes into an infinite loop when two policies are invoked. | ||||||
CSCdr14092 | Multiple rules are executed in an OR condition. | ||||||
CSCdr14104 | Validation does not fail for p[olicy grouping with keyword example: cd /Radius/Policy | ||||||
CSCdr14133 | A keyword shown in a rule name is not validated properly. The following is invalid: cd /Radius/Rules | ||||||
CSCdr14141 | Validation does not occur fro attributes under a rule. The following configuration passes validation but should not: cd /Radius/Rules | ||||||
CSCdr14189 | Problem with tunnel attributes with tag0*. When you do the following configuration changes, they should fail validation. They do fail validation, however, the RADIUS server stops. cd /Radius/Profile | ||||||
CSCdr14192 | No validation for tunnel attribute. The following configuration should fail validation, however, it does not: cd /Radius/Profile | ||||||
CSCdr14210 | The server cores when you start the LDAP server first, then send a simple packet (for example, | ||||||
CSCdr14883 | Client secret not dynamically updated. | ||||||
CSCdr18965 | Erroneous log message after changing remote server secret. | ||||||
CSCdr18971 | Adding a remote server from the command line fails. | ||||||
CSCdr18977 | Reload ordering problem with scripts may cause server to core. Reproduce this by:
In most cases, an error message stating that the script is invalid is displayed, which occasionally causes the server to core. | ||||||
CSCdr18984 | Erroneous log message about shared secrets. | ||||||
CSCdr18990 | Ghost remote server appears in stats output. |
This section provides the following information about the 1.3 Cisco Access Registrar release:
The 1.3 Cisco Access Registrar release includes the following new features:
1. Concurrent local and proxy accounting streams.
2. Multi-valued RADIUS attribute support.
3. Enhanced duplicate request filtering.
4. Server log file roll over.
5. Statistics output redirection.
Table 9 describes the bugs fixed in the 1.3 Cisco Access Registrar release.
| Bug Number | Description |
|---|---|
CSCai02371 | The two new example scripts add-example-configuration.rc and delete-example-configuration.rc do not automatically reload the server. After running either script, you must manually reload the server to update the database with your changes. |
CSCai02626 | Enhancement: aregcmd can now be used to set the maximum size of the Cisco Access Registrar log files, and the number of log files kept. |
CSCai03094 | Can't eject the CD ROM after pkgadd if it is performed within the cdrom directory. |
CSCai03185 | Cisco Access Registrar does not assign an IP address (or allocate any other resources) when the reply from a remote RADIUS server contains a State attribute. |
CSCai03346 | The AddProfile method does not come back with an error code if the Profile is not found. |
CSCai03376 | Enhancement: the SessionManager for an Accounting-Request is automatically determined by the SessionManager chosen for the previous Access-Request for the same NAS and NAS-Port. |
CSCai03389 | Enhancement: The OutagePolicy on a Service now applies to Accounting-Requests, as well as Access-Requests. |
CSCai03392 | The Adaptive Round Trip Time (RTT) algorithm can cause the dynamic timeout value to become too small and cause invalid timeouts on a RemoteServer. |
CSCai03501 | If a NAS fails to return the State Attribute in Accounting-Requests, SessionManagement does not operate properly. |
CSCai03579 | The RemoteServer name should be displayed with an IP address in aregcmd stats output. |
CSCai03580 | Enhancement: aregcmd now supports the $PAGER environment variable. Currently, this is only used when presenting statistics, and it is only used in interactive mode. |
CSCai03584 | Adding attributes in the standard attribute space with the same name as an existing vendor-specific attribute causes aregcmd to fail. |
CSCai03719 | Enhancement: "Static" IP Addresses (from Profiles or Proxies) are now visible in Session data. See "Session Notes" feature for more information. |
CSCai03789 | Incorrect error message displayed when NULL (zero) is passed as a string value to any of the REX API put functions. |
CSCai03800 | Cisco Access Registrar crashes when a Client is configured with type Proxy, and a request either contains a NAS-Identifier attribute that matches that Client's name, or the request contains a NAS-IP-Address attribute with that Client's IP address. |
CSCai03814 | Cisco Access Registrar should identify the name and IP address of a RemoteServer in any failure log message. |
CSCai04088 | Iterating through Vendor-Specific attributes with a REX or TCL script/service may find the wrong attributes in the Request/ Response dictionary. |
CSCai04101 | After initially installing the product, if the examples are installed, aregcmd may ask the admin to save (upon exit) even if no changes were made. |
CSCdk83312 | Trailing NULL characters included at the end of passwords returned from LDAP may cause PAP/CHAP authentication to fail. |
CSCdk86146 | Out of sequence Accounting "Start" requests can create orphaned sessions, possibly leaking dynamic resources. (See "Session Creation" for solution details). |
Table 10 describes the known bugs in the 1.3 Cisco Access Registrar release.
| Bug Number | Description |
|---|---|
CSCai02130 | When accounting files are rolled, they are renamed to a file that includes the date range of the entries inside. Unfortunately, the creation and modification times of the file are in UTC, while the time stamp on each accounting record is in local time. Thus, there is a time skew between the times used for the name of the rolled accounting file and the time stamp for the first and last record in the file. |
CSCai02242 | Cisco Access Registrar displays the message, "Database lock attempt failed" if you stop the server while it is still in the process of starting. If this occurs, you will not lose any data. |
CSCai02273 | Validation succeeds when multiple administrators enter the same user in the UserList. Instead of reporting a conflict, both administrators will be modifying the same user records. |
CSCai02319 | Validation doesn't check whether a deleted RemoteServer or a deleted ResourceManager is referred to by a Service or a SessionManager, respectively. |
CSCai02320 | After a save, the aregcmd command displays the value of a new Networks range in an IPX-dynamic ResourceManager in decimal. To restore the display, log in to the cluster again. |
CSCai02432 | Cisco Access Registrar does not check the Response-Type which may be set by a Script immediately after running the Server, or Vendor Scripts. It is checked after the Client Script point. |
CSCdk82488 | aregcmd will let the administrator add a VSA with the same name as an existing standard attribute, or a VSA for another vendor. |
CSCai02946 | Requests authenticated with a TACACS service do not get reflected in the Cisco Access Registrar server statistics. |
This section provides information that was missing from the 1.3 Cisco Access Registrar documentation.
If you have the situation where a Cisco Access Registrar RADIUS server is acting as a forwarding server and proxying requests to one or more remote RADIUS servers, the Accounting-On and Accounting-Off requests are only proxied to remote servers when the request is directly from a NAS.
Note, Cisco Access Registrar only forwards the Accounting-On or Accounting-Off requests when they come directly from a NAS. It does not forward requests when they are from a proxy. Therefore, if you have a chain of forwarding servers, the Accounting-On or Accounting-Off request will not be forwarded for more than one hop.
When Cisco Access Registrar is unable to write accounting records to disk, this information may be lost. Cisco Access Registrar continues to run, however, it does not acknowledge accounting requests. After you have made disk space available, you must reload Cisco Access Registrar to cause the Accounting Services to resume writing to disk.
Note, because Cisco Access Registrar does not buffer the requests it could not write to disk, this information is lost unless the client (NAS or proxy) resends the accounting requests. Fortunately, most NASs retry accounting requests until they are acknowledged.
Some versions of USR NASs do not generate correct signatures for accounting requests. When an accounting request packet has an incorrect signature, Cisco Access Registrar drops the packet. A workaround for this problem is to set the Vendor of the client to be USR-IgnoreAccountingSignatures. This causes Cisco Access Registrar to not attempt to verify that the signature is correct.
This section provides information about known problems that exist in the 1.3 Cisco Access Registrar documentation.
1. In Appendix A, page A-7, the method allocMemory should instead be called allocateMemory (like the method declaration).
2. The following items pertain to Appendix D:
This section lists the components of the Cisco Access Registrar 1.5 product:
1. Cisco Access Registrar 1.5 product CD.
2. Release Notes for Cisco Access Registrar, Release 1.5 (part number 78-7189-02 (this document)).
3. Cisco Access Registrar Getting Started Guide (part number 78-6600-01).
4. Cisco Access Registrar User Guide (part number 78-6601-01).
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Posted: Thu Apr 6 15:30:34 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.