Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Request Routing

 

When Steel-Belted Radius Carrier receives a RADIUS authentication or RADIUS accounting request, it examines the attributes in the request to match the request with the service that can best respond to it:

  • RADIUS authentication or accounting

  • Proxy RADIUS authentication or accounting

  • Tunnel authentication

  • Directed authentication or accounting

This matching process (request routing) uses the information in the User-Name attribute (in which routing information is supplied as a prefix or suffix to the user’s account name), the Called-Station-Id attribute (DNIS), or other attribute(s) to route the request.

Steel-Belted Radius Carrier follows the order of matching techniques configured in the [Processing] section of proxy.ini. For example, it may check User-Name and Called-Station-Id attributes, then it checks the attributes you have mapped to realms. It uses the first routing destination it finds.

An exception to this routing logic is when the authentication request is handled by a directed realm and that directed realm also has accounting enabled. When this occurs, the class attribute will have a subattribute called VirtualRealm added to it. If the accounting request received by the radius server has the class attribute sent in the Access Accept, the routing logic above is bypassed and the directed realm listed in the VirtualRealm field will be used to process the accounting request.

Match Rules

Match Rules

In simple cases, each entry in the [Realms] or [Directed] sections of the proxy.ini file consists of the name of a domain. For prefix- and suffix-based realm matching, the domain name is taken from the User-Name attribute (for example, other.com in user@other.com). The domain name also supplies the root of the name of the configuration file that specifies the treatment for that realm (for example, other.com.pro or other.com.dir).

Match rules extend the format of lines in the [Realms] or [Directed] sections by allowing leading and trailing wildcard support and by allowing multiple entries to be mapped to the same realm.

Match rules in the [Realms] or [Directed] sections of the proxy.ini file take the form:

  • Leading wildcards allow you to match any domain name that ends with the appropriate domain name string and map it to a realm name:

  • Trailing wildcards allow you to match any domain name that begins with the appropriate domain name string and map it to a realm name:

  • Direct matching allows you to map a domain name to a realm name:

A standalone wildcard character allows you to match any domain name that does not meet the criteria of a more specific rule:

You can use match rules to map more than one entry in the [Realms] or [Directed] section of proxy.ini to a realm. When Steel-Belted Radius Carrier performs prefix or suffix processing of the User-Name, it isolates the realm portion of the User-Name attribute and then searches through the match rules to find the one that matches the realm information most closely. The best match is the one that specifies the largest number of non-wildcard characters in the rule.

For example, assume the following entries are present in the [Realms] or [Directed] section of your proxy.ini file:

Table 16 identifies what realms Steel-Belted Radius Carrier chooses for different User-Name values.

Table 16: Realm Mapping Example

User-Name

Mapped Realm

bob@usa.msn.com

realm2

alice@scotland.uk.msn.com

realm3

lauren@wales.uk.msn.com

realm3

rich@germany.msn.com

realm1

julia@indiana.usa.msn.com

realm1

ramon@other.com

realm4

seema@other.edu

realm5

Realm names can appear more than once within the [Realms] or [Directed] section of proxy.ini to point multiple match rules to the same realm. For example, you can enter the following settings in the [Realms] or [Directed] section of your proxy.ini file:

These entries map any username with a domain of usa.msn.com or uk.msn.com to realm2, and map other domain ending in msn.com to realm1.

You cannot enter duplicate realm lines (with or without match rules) in the [Realms] or [Directed] section of your proxy.ini file, and you cannot enter the same match rule on multiple lines.

You cannot combine leading and trailing wildcards in the same match rule. If you do so, the trailing match rule is ignored.

User-Names with a Single Delimiter

User-Names with a Single Delimiter

An incoming User-Name string can be decorated with a single delimiter separating the user’s name from a destination name. A User-Name decorated in this manner can indicate a proxy RADIUS realm, a directed realm, a tunnel, or a proxy entry that is not a member of any realm.

Note

To prevent unexpected routing results, you must ensure that the name of every realm, tunnel, and proxy entry is unique across your entire Steel-Belted Radius Carrier configuration.

User-Names with a Single Tunnel Delimiter

User-Names with a Single Tunnel Delimiter

If the delimiter matches the currently configured delimiter for tunnels, and if the current name-parsing convention for tunnels is suffix, the User-Name is understood to be:

 

If the current name parsing convention for tunnels is prefix, the User-Name is understood to be:

Where:

  • User is the name of the dial-in user

  • TunnelName identifies the destination

  • <SuffixDelimiter> or <PrefixDelimiter> is a delimiter character such as @, / or !

If a tunnel entry is found that matches the TunnelName, and the request is for authentication, Steel-Belted Radius Carrier proceeds with tunnel authentication.

Note

Tunnel delimiters are specified in the Name Parsing page (described in Configuring RADIUS Tunnels). You may use either the prefix or the suffix naming convention for tunnels, but not both. You can also choose the tunnel delimiter character (‘@’, ‘/’, and so forth). The conventions you define in the Name Parsing page apply to all tunnels defined on the server.

User-Names with a Single Realm Delimiter

User-Names with a Single Realm Delimiter

If the User-Name contains a single delimiter that matches the currently configured suffix delimiter for realm destinations, the User-Name is understood to be:

  User<SuffixDelimiter>RealmName

If the User-Name contains a single delimiter that matches the currently configured prefix delimiter for realm destinations, the User-Name is understood to be:

  RealmName<PrefixDelimiter>User

Where:

  • User is the name of the dial-in user

  • RealmName identifies the destination

  • <SuffixDelimiter> or <PrefixDelimiter> is a delimiter character such as @, / or !

Steel-Belted Radius Carrier attempts to find a destination that matches RealmName in one of four places, as summarized in Table 17.

Table 17: Realm Name Matching

If a match is found in:

Then Steel-Belted Radius Carrier does this:

[Self] section of the radius.ini file.

Steel-Belted Radius Carrier services the request locally.

The [Directed] section of the proxy.ini file.

Steel-Belted Radius Carrier routes the request to a specific authentication or accounting method on the local server, according to the rules in the corresponding RealmName.dir file.

The [Realms] section of the proxy.ini file.

Steel-Belted Radius Carrier routes the request to the proxy RADIUS realm called RealmName according to the rules in the corresponding RealmName.pro file. See Target Selection within a Realm.

A proxy entry in the Steel-Belted Radius Carrier database

Steel-Belted Radius Carrier uses the information in the proxy entry (IP address, UDP port, and shared secret) to forward the RADIUS request.

Note

Realm delimiters and naming conventions are defined in the proxy.ini file. You can define different delimiters for prefixes and suffixes. The conventions you define in proxy.ini apply to all types of realm defined on the server (both proxy realms and directed realms).

User-Names with Multiple Suffix Delimiters

User-Names with Multiple Suffix Delimiters

If the User-Name contains multiple realm delimiters (User<Delimiter>RealmName <Delimiter>RealmName<Delimiter>RealmName) and the delimiter character matches the current RealmSuffix setting in the [Configuration] section of proxy.ini, the name parsing strategy is as follows:

  1. Steel-Belted Radius Carrier finds the leftmost RealmName in the User-Name that is also listed in the [Self] section of its radius.ini configuration file.

  2. If a matching RealmName was found in Step 1, and there is no other RealmName to the left of it, then Steel-Belted Radius Carrier services the request locally, without forwarding.

  3. If a matching RealmName was found in Step 1, but there is another RealmName to the left of it, then Steel-Belted Radius Carrier routes the request to the RealmName listed immediately to the left of the matching RealmName. The routing is controlled by the corresponding RealmName .pro or RealmName .dir file.

  4. If no RealmName match was selected in Steps 1, 2, or 3, then Steel-Belted Radius Carrier routes the request to the rightmost RealmName in User-Name. The routing is controlled by the corresponding RealmName .pro or RealmName .dir file.

According to these rules, if the realm suffix Delimiter character is ‘@’, and the User-Name value matches realm suffix naming conventions, and the [Self] section of radius.ini lists one realm called bigserver, then incoming User-Name values are parsed as described in Table 18.

Table 18: Realms in User-Names

Request

Action

fred@bignet@bigserver

Routed to the realm called bignet.

fred@bignet@bigserver@smallnet

Routed to the realm called bignet.

fred@bignet@smallnet

Routed to the realm called smallnet.

fred@bigserver@bignet

Handled locally on bigserver.

User-Names with Multiple Prefix Delimiters

User-Names with Multiple Prefix Delimiters

If the User-Name contains multiple realm delimiters:

and the Delimiter character matches the current RealmPrefix setting in the [Configuration] section of proxy.ini, the name parsing strategy is the reverse of the suffix strategy described above. In detail:

  1. Steel-Belted Radius Carrier finds the rightmost RealmName in the User-Name that is also listed in the [Self] section of its radius.ini configuration file.

  2. If a matching RealmName was found in Step 1, and there is no other RealmName to the right of it, then Steel-Belted Radius Carrier services the request locally, without forwarding.

  3. If a matching RealmName was found in Step 1, but there is another RealmName to the right of it, then Steel-Belted Radius Carrier routes the request to the RealmName listed immediately to the right of the matching RealmName. The routing is controlled by the corresponding RealmName .pro or RealmName .dir file.

  4. If no RealmName was selected in Steps 1, 2, or 3, then Steel-Belted Radius Carrier routes the request to the leftmost RealmName in the User-Name. The routing is controlled by the corresponding RealmName.pro or RealmName.dir file.

According to these rules, if the realm prefix Delimiter character is ‘!’, and the User-Name matches realm prefix naming conventions, and the [Self] section of radius.ini lists one realm called bigserver, then incoming User-Name values are parsed as described in Table 19.

Table 19: Realms and User-Names

Request

Action

superserver!bignet!fred

Routed to the realm called bignet.

smallnet!bigserver!bignet!fred

Routed to the realm called bignet.

smallnet!bignet!fred

Routed to the realm called smallnet.

bignet!bigserver!fred

Handled locally on bigserver.

Undecorated User-Names

Undecorated User-Names

An undecorated User-Name is a username that does not include realm identification information. When realm support for undecorated User-Names is enabled, Steel-Belted Radius Carrier routes authentication requests that contain undecorated User-Name attributes to the proxy realm or directed realm designated in the [Realms] or [Directed] section of the proxy.ini file.

Undecorated User-Name support allows you to specify a realm to handle any request containing a User-Name that does not contain realm identification information.

Steel-Belted Radius Carrier uses the following logic to determine if a User-Name is undecorated:

  1. If Suffix is enabled in the [Processing] section of the proxy.ini file and the User-Name contains the specified RealmSuffix character, the User-Name is not undecorated. By default, @ is the default RealmSuffix character and that Suffix is enabled if the proxy.ini file does not include a [Processing] section.

  2. If Prefix is enabled in the [Processing] section of the proxy.ini file and the User-Name contains the specified RealmPrefix character, the User-Name is not undecorated. By default, / is the default RealmPrefix character and that Prefix is enabled if the proxy.ini file does not include a [Processing] section.

  3. If neither of the above statements is true, the User-Name is undecorated.

Configuring Undecorated User-Name Support

Configuring Undecorated User-Name Support

To configure undecorated User-Name support in Steel-Belted Radius Carrier:

  1. Add an Undecorated entry to the [Processing] section of proxy.ini.

    If the proxy.ini file does not include a [Processing] section or if the Undecorated entry is commented out or not present, undecorated User-Name processing is disabled.

  2. Associate an <undecorated> marker with a proxy realm (in the [Realms] section of proxy.ini) or a directed realm (in the [Directed] section of proxy.ini).

    Only one realm listed in the [Realms] or [Directed] section of proxy.ini can be configured with the = <undecorated> setting. If more than one realm is associated with the = <undecorated> setting, Steel-Belted Radius Carrier enables the first entry it finds and writes an error message identifying the duplicate realms to the server log file.

  3. Verify that the private directory for Steel-Belted Radius Carrier includes a realm.pro file (for the proxy realm associated with undecorated User-Name processing) or realm.dir file (for the directed realm associated with undecorated User-Name processing) that matches the realm specified in Step Configuring Undecorated User-Name Support

    For example, if you enter other.com = <undecorated> in the [Realms] section of proxy.ini, you must have an other.com.pro file in the Steel-Belted Radius Carrier directory. If the applicable realm .pro file is not found, Steel-Belted Radius Carrier writes an error message noting the realm has not been enabled to the server log file.

Example

Example

The following sections of proxy.ini illustrate how undecorated User-Name support is configured in Steel-Belted Radius Carrier.

In this example, any authentication request that contains undecorated User-Name attributes is handled by the other.com realm. Successful authentication requests that are handled by the selected realm results in a Class attribute that records the name of the realm so that accounting requests resulting from the session can be handled by the same realm.

This is different from cases where a decorated User-Name (that is, a User-Name that contains a prefix or suffix delimiter) does not match explicit realm mapping rules. For example, since no matching rule for littlecorp.com is configured, a request containing a User-Name value of user@littlecorp.com would fall through to local processing and result in a rejection if no matching user is found.

Note

All settings are reloaded on receipt of a SIGHUP (1) signal.

Request Routing by DNIS

Request Routing by DNIS

If the Called-Station-Id attribute is found in the RADIUS request, the request can be routed based on DNIS (Dialed Number Information Services). Steel-Belted Radius Carrier checks its administration database and server configuration files for a DNIS string that matches the value of the incoming Called-Station-Id attribute. If found, the matching string might be in one of three places:

  • A tunnel entry’s Called Station Id list. If a match is found here, and the request is for authentication, Steel-Belted Radius Carrier performs tunnel authentication. See Tunnel Authentication Sequence.

  • The [Called-Station-ID] section of a RealmName.dir file. If a match is found here, Steel-Belted Radius Carrier handles the request locally using the authentication or accounting methods identified in the RealmName.dir file. See Configuring a Directed Realm.

  • The [Called-Station-ID] section of a RealmName.pro file. If a match is found here, Steel-Belted Radius Carrier routes the request to the proxy RADIUS realm called RealmName using the rules defined in the RealmName.pro file. See Target Selection within a Realm.

    Note

    We recommend that you use DNIS strings that are unique across all tunnel entries, all RealmName.dir files, and all RealmName.pro files. If you duplicate a DNIS string anywhere in your Steel-Belted Radius Carrier configuration, the request routing results might be unexpected.

Request Routing by Any Attribute

Request Routing by Any Attribute

You can map the presence or absence of any attribute or attribute/value pair in an incoming packet to a specific realm, by providing an [AuthAttributeMap] or [AcctAttributeMap] section in the proxy.ini configuration file.

You can route all of the packets for a session to a realm based on attributes in the Access-Request (the [AuthAttributeMap] section), or you can route the session’s accounting packets to a different realm, based on attributes found in these packets (the [AcctAttributeMap] section).

Attribute mapping can be used for proxy RADIUS realms and for directed realms. You cannot use this feature when forwarding packets to a proxy target that is not a member of a realm.

Local Services

Local Services

If the RADIUS request does not contain routing information (or at least, it does not contain any routing information that Steel-Belted Radius Carrier has been configured to recognize), it is processed locally on the Steel-Belted Radius Carrier server. Authentication follows the authentication methods list in the Authentication Methods page. No User-Name parsing is performed; the entire string is understood to be the user’s name. Accounting is controlled by the server’s main account.ini file and (for external database accounting) .acc file.

Control over Routing Methods

Control over Routing Methods

By default, the rules for determining the destination of a request are applied in the following order by default:

  1. Apply Suffix delimiter rules

  2. Apply Prefix delimiter rules

  3. Apply DNIS rules

  4. Apply Attribute Mapping rules

You can specify which methods you want used for request routing and the sequence in which methods are applied.