LDAP Rules and Limitations

While the LDAP virtual schema diagram shows as much of the detail of the LDAP virtual schema as possible, take these rules and limitations into consideration.

• Bind request—All attempts to perform operations on the virtual schema must be preceded by an LDAP Bind request that authenticates the administrator to the Steel-Belted Radius Carrier server. The Bind request must reference a Steel-Belted Radius Carrier administrative account and must provide the password that authenticates that account. This translates into the following command line options for each invocation of the LDAP utilities:

  Where AdminName is the administrative account name and AdminPassword is its password.

• Uppercase and lowercase—The uppercase/lowercase rules for object names are the same as in the Web GUI; that is, almost all object names are stored in the database in uppercase format. The exception to this rule is that UNIX User/Group names are maintained in the case specified in the LDIF files.

• Attributes—When you enter attributes, make sure that the attribute name matches the name found in the dictionary and that the attribute’s value is consistent with the syntax type for the attribute. The LDAP virtual schema does not list all the dictionary attributes that are available in Steel-Belted Radius Carrier.

• IP addresses—The ipaddr-pool type in the dictionary can represent an IP address or a pool name. If the value specified begins with the marker string [pool], the token that follows the marker string is assumed to be an IP pool name; otherwise, it must be a valid IP address. If it is neither, the operation fails.

  Address ranges in IP address pool objects are specified in the form IPaddress:NumberOfAddresses. An example of a valid range is 128.22.12.45:34.

• Substrings—An attribute may have a value that consists of a list of strings. For example, the DNIS list in a tunnel entry and the authentication method list may consist of multiple substrings. The rule for specifying the data portion for these lists is that semicolons must delimit substrings. For example, a DNIS list for a tunnel entry might be specified as 555-1212;5551212. If a semicolon needs to appear inside a substring, it must have an escape character (\) before it.

• Password syntax—Passwords that are set or retrieved from the database may consist of one of the following:

  • A clear-text password of the form {x-clear}clear-text-password-string if the password is weakly encrypted in the database.

  • A string of the form {x-md5}xxxxxxxxxxxxxxxxxxxxxxxxxxxxx if the password is stored as a one-way md5 hash.

  • A string of the form {x-md5}[encrypt]clear-text-password-string indicates that, although the password is specified in clear-text form, it is to be stored as a hash. This is applicable only for setting the password through LCI.

  White space in a password is treated as follows:

  • When clear-text passwords are specified, the password is assumed to begin immediately after the right brace or right bracket. Adding a white space character, such as a space or tab, after the right brace or right bracket causes the white space to be considered part of the password.

  • White space entered at the beginning of the attribute (before the left brace or left bracket) is ignored.

  • White space entered between the right brace of {x-md5} and the left bracket of [encrypt] is ignored.

  • All white space specified in the hexadecimal sequence describing a password hash is ignored.

• Profiles, check lists, and return lists—Steel-Belted Radius Carrier supports user definitions that include attribute subtractions of profile entries. To specify that a user attribute is to be considered a subtraction of a profile attribute, preface the attribute value with the string %subtract%.

  Steel-Belted Radius Carrier permits user and profile check lists to include default values for attributes. Configuring a default value for an attribute means that, if a RADIUS request does not include this attribute, the request is not rejected. Instead, the value supplied as the default is used as if it were received as part of the request. To specify that a check list attribute is to be considered a default attribute, preface the attribute value with the string %default%.

  Steel-Belted Radius Carrier permits user and profile return lists to include attributes whose values are set by copying the contents of received attributes. This feature is referred to as attribute echoing. To specify that a return list attribute is to be treated as an echo attribute, enter %echo% for the attribute value.

• Unspecified or 0.0.0.0 NAS IP address—When you display acct_stats_by_nasipaddr information, any NAS entries with an unspecified IP address or an IP address of 0.0.0.0 are omitted. Similarly, when you display acct_stats_by_nas information, any NAS entries with an unspecified IP address or an IP address of 0.0.0.0 have their nasipaddr attribute omitted.

• Duplicate NAS IP addresses—When displaying acct_stats_by_nasipaddr information, two NAS entries that contain the same (non-zero) IP address cause information about one of the entries to be displayed twice. This is the result of the ambiguity of the query and is not a bug.

• RADIUS client information displayed after deletion—If you define a RADIUS client entry, send some accounting traffic to it, and then delete the entry, the output of ldapsearch queries continue to list the deleted RADIUS client so that the per-NAS statistics add up to the total NAS statistics.

Using the LCI to Define Structured Attributes in Check Lists and Return Lists

Using the LCI to Define Structured Attributes in Check Lists and Return Lists

The LCI (LDAP Control Interface) has been extended to facilitate structured attributes in check lists and return lists. Subject to certain restrictions, a structured attribute must be defined as a whole (as opposed to defining individual subattributes) using either the raw hexadecimal representation of the entire structured attribute’s binary payload, or an XML representation of the structured attribute hierarchy using the format outlined in this section.

When the response packet is formatted, the hexadecimal or XML data is formatted into the packet. For XML data, it is parsed into a structured attribute hierarchy and then formatted as normal.

If the hexadecimal representation is used, then the entire RADIUS attribute must be specified. If the XML representation is used, then it is not necessary to specify subattributes for which default values are defined.

The LCI assumes the data is in the hexadecimal representation unless the following conditions are met for the XML representation:

• The XML representation must be at least 16 characters and not more than 8192 characters in length.

• The XML representation must obey generic XML grammar. For example: it must begin and end with angle brackets, all angle brackets must be properly paired, and so on.

The LCI does not validate the contents of either hexadecimal or XML values. The LCI accepts hexadecimal and XML representations with flawed contents. It is the user's responsibility to ensure that the content is legal and, if XML representation is used, that the XML obeys the schema described in LCI XML Format and shown in Figure 200.

LCI XML Format

LCI XML Format

Make the XML hierarchy reflect the hierarchy defined in the .jdict subattribute dictionary file in a nested set of <attribute> elements. All <attribute> elements must have a name attribute. Ensure that groups and sequences (the parent attribute, and subattribute types) are represented by <attribute> nodes without a value attribute, and will further <attribute> elements as children.

The proper format is shown in Figure 200.

Figure 200: LCI XML Format

For more information about subattributes and an example of the proper XML format you need to use with the LCI, as well as structured attribute dictionary definitions, see the SBR Carrier Reference Guide.