The vendor.ini initialization file contains information that allows Steel-Belted Radius Carrier to work with the products of other vendors.
[Vendor-Product Identification] Section
[Vendor-Product Identification] Section
The [Vendor-Product Identification] section (Table 70) of vendor.ini identifies and provides information about the network access devices that can be used with Steel-Belted Radius Carrier.
Table 70: vendor.ini [Vendor-Product Identification] Syntax
Specifies the name of the product. A product name must be unique, cannot include blanks and must consist of 127 or fewer characters. These product names are used only in the Make or Model list in the RADIUS Clients List page. This list is used when adding a new RADIUS client or when selecting a vendor-specific attribute.
Specifies the dictionary file to use for this product. The dictionary file must be located in the same directory as the Steel-Belted Radius Carrier daemon or service. You do not need to specify an extension on the dictionary name; Steel-Belted Radius Carrier automatically attaches an extension of .dct to the dictionary names listed in this parameter.
Specifies the attribute used for call filter functions. Used only by Ascend/Lucent network access devices.
Specifies the attribute number in which a network access server sends responses to challenge sequences.
If not specified, the default behavior is to expect responses to be encoded in the User-Password attribute.
Specifies the attribute used for data filter functionality. Used only by Ascend/Lucent network access devices.
Used for inbound proxy RADIUS servers that send username information in a decorated format. For example, if a proxy RADIUS server sends usernames of the form username@company, then specifying @ results in the @ delimiter character and all text after the @ delimiter character being discarded for authentication purposes; the string username is used.
Used for inbound proxy RADIUS servers that send username information in a decorated format. For example, if a proxy RADIUS server sends usernames of the form company$username, then specifying $ results in the $ delimiter character and all text before the $ delimiter character being discarded for authentication purposes; the string username is used.
Help context for the vendor’s product in the vendor information help file.
If set to Yes, the digital signature of accounting packets based on the shared secret is ignored. This accommodates devices that do not properly sign accounting packages.
Default value is No.
Determines whether Steel-Belted Radius Carrier may infer that one user has logged off if the port that was assigned to that user is now being used by another user.
Specifies a maximum EAP fragment length on a make/model basis. The maximum EAP fragment length emitted by TLS or TTLS is the lesser of the maximum specified in their .eap/.aut files and this setting.
Default value is 1020. This may be inefficient, however, as the fragment length must be set to a number low enough to work with all of a customer's Access Points.
Specifies the name of the section in the vendor.ini file that contains rules for dynamically determining the product associated with an accounting request by the contents of the request packet.
Specifies the name of the section in the vendor.ini file that contains rules for dynamically determining the product associated with an authentication request by the contents of the request packet.
If set to No, the Class attribute is not sent to the client on Access-Accept. (This feature is designed to accommodate devices that do not handle the Class attribute properly.)
Default value is Yes.
Specifies an attribute name. If an accounting request contains the attribute specified in this parameter for a particular vendor, sessions will not be created in CST. This attribute must be valid for the dictionary used by the Make/Model (vendor-product) entry.
Note: This setting considers only the specified attribute and does not consider the value of the attribute.
send-extra- attributes-on -auth-only
The WiMAX specification revision number. The WiMAX mobility module changes behavior based on the revision number. Valid values are 1.0 and 1.2.
After you define a Vendor-Product entry (Table 71) in vendor.ini, the name of this entry can be selected in the RADIUS Clients dialog as a possible value for the Make/model field. The ProductScanAuth and ProductScanAcct settings can be used within a VendorProduct entry to permit dynamic make/model selection to occur. These settings enable Steel-Belted Radius Carrier to examine the incoming packet to determine the make/model of the network access server that originated the packet.
A dynamic Vendor-Product entry might appear as:
Table 71: vendor.ini Product-Scan Syntax
Creates a label that appears as a selection in the Make/Model list in the RADIUS Clients List page in Web GUI.
Applies only to authentication servers. name references a section heading that appears elsewhere in vendor.ini.
Applies only to accounting servers. name references a section heading that appears elsewhere in vendor.ini.
Provides rules that govern dynamic make/model selection. These rules apply on authentication requests if the value name is assigned to Product-Scan-Auth; they apply on accounting requests if the value name is assigned to Product-Scan-Acct.
Product is a product name. String is a regular expression to match against attributes in the packet. Character by character, Product must match a Vendor-Product value defined elsewhere in the vendor.ini file.
The default vendor.ini provided with Steel-Belted Radius Carrier includes a number of Vendor-Product values from which you may choose. Each value corresponds to a vendor-specific RADIUS attribute dictionary.
The list of product names and strings is tried in order. If the packet does not come from the first device, the next is tried, and so on until the last entry in the list is tried.
You can set up a default at the end of the list by making sure the last Product entry in the list has no String assigned. If no match is found earlier in the list, Steel-Belted Radius Carrier assumes that the packet comes from the type of device specified in the final entry.
The following example is appropriate in a configuration where the NAS devices are primarily Ascend devices:
Product-Scan-Auth = Bigco Special Scan [Bigco Special Scan] Ascend MAX Family = \x2c? Nortel Versalar Remote Access Concentrator = \x1a?\x00\x00\x06\x30 US Robotics NETServer = \x1a?\x00\x00\x01\xad Ascend MAX Family =
The preceding example sets up dynamic make/model selection for authentication and states that the identity of the client device is determined by seeking matches in this order:
Is the attribute with identifier number 0x2c (Acct-Session-Id), with a value of any length (indicated by the question mark character), found in the incoming authentication packet? If so, the originating network access server is a member of the Ascend MAX Family; use that vendor-specific dictionary.
Is the vendor-specific attribute with identifier number 0x1a (Vendor-Id), with a value of any length (indicated by the question mark character), present in the packet? If so, does it have the value 1584 (0x630) which indicates a Nortel Networks Versalar RAC? If so, use that vendor-specific dictionary (provided with Steel-Belted Radius Carrier).
Is the Vendor-Id attribute present, with any length, and if so, does it have the value 429 (0x1ad) which indicates a US Robotics NETServer? If so, use that vendor-specific dictionary (provided with Steel-Belted Radius Carrier).
If no match can be found using the rules specified in this section, then use the vendor-specific dictionary for the Ascend MAX Family.
Include a default entry in this section. When there is no default, if an Access-Request is received with no vendor-specific attributes of any kind, the user may be rejected due to invalid resources, as the RADIUS server cannot associate a valid dictionary with the request. Using the example:
- Standard RADIUS - =
as the last line in this section is a safe configuration.